fix: remove enable_custom_domain_in_emails from managed tenant flags

[ankita10119]

🔧 Changes

Removes enable_custom_domain_in_emails from the managed tenant flags allowlist (allowedTenantFlags) to prevent import failures in environments without a ready custom domain.

Problem: The flag was included in allowedTenantFlags, causing it to be:

1. Included in export output (tenant.yaml) even though it is deprecated
2. Sent to the Management API during import, resulting in a 400 Bad Request error on tenants that do not have a custom domain with status: "ready" - aborting the entire tenant processChanges stage and leaving no tenant settings applied

Changes:

• Removed enable_custom_domain_in_emails from allowedTenantFlags in src/tools/auth0/handlers/tenant.ts - the existing removeUnallowedTenantFlags() function now strips it on both the export and import paths automatically
• Updated the deprecation warning message to accurately state the flag is no longer applied, and directs users to migrate to customDomains[].is_default
• Updated unit test to assert the flag is absent from the Management API payload, not just that the warning is logged
• Removed the flag from three e2e testdata fixtures that used it as import input

Migration: Users should remove enable_custom_domain_in_emails from their tenant configuration files and use the is_default field on customDomains instead:

customDomains:
  - domain: mail.example.com
    type: auth0_managed_certs
    tls_policy: recommended
    is_default: true

📚 References

• Supersedes the deprecation warning introduced in feat: Add support for default custom domain and deprecation warning for enable_custom_domain_in_emails  #1330 -the flag is now fully removed from management rather than just warned about

🔬 Testing

Unit tests: Updated test in test/tools/auth0/handlers/tenant.tests.ts verifies:

• Deprecation warning is still logged when the flag is present in input
• The flag is not present in the payload sent to client.tenants.settings.update()

Manual export test: Running node lib/index.js export against a tenant with enable_custom_domain_in_emails: true confirms:

• The flag no longer appears in the exported tenant.yaml
• The export log lists the flag under the existing "incompatible flags" warning

Not tested end-to-end for import (requires a tenant without a custom domain): the import path is covered by the unit test and by code analysis - removeUnallowedTenantFlags() strips the flag before the API call in processChanges().

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.10%. Comparing base (f7873f7) to head (901507a).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1401   +/-   ##
=======================================
  Coverage   80.10%   80.10%           
=======================================
  Files         153      153           
  Lines        7099     7099           
  Branches     1566     1566           
=======================================
  Hits         5687     5687           
  Misses        760      760           
  Partials      652      652           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[harshithRai]

Now that enable_custom_domain_in_emails is removed from allowedTenantFlags, removeUnallowedTenantFlags() will already emit a generic incompatible flag warning for it.

So in the same import run the user sees two contradictory warnings, one says the flag can likely be removed from their config, the other says it has already been removed from management.

For example, with flags: { enable_custom_domain_in_emails: true } in their config, they'd see:

WARN: The following tenant flag has not been updated because deemed incompatible with the target tenant: enable_custom_domain_in_emails. This flag can likely be removed from the tenant definition file...

WARN: The "enable_custom_domain_in_emails" tenant flag is deprecated and has been removed from management. It will not be applied during import. Use the "is_default" field on customDomains instead.