Add custom email domain to Azure Communication Services

[tjementum]

Summary & Motivation

Switch transactional email sending from the auto-provisioned *.azurecomm.net Azure-managed sender to a brand-aligned no-reply@<custom-domain> sender on Azure Communication Services. The Azure-managed sender disqualifies the brand from DMARC alignment, sender reputation tied to the custom domain, and anti-phishing signals such as Apple Mail's OTP autofill, which requires the sender's eTLD+1 to match the bound verify-form domain.

• Add an optional domainName parameter to cloud-infrastructure/modules/communication-services.bicep. When set, the module provisions a CustomerManaged domain alongside the existing AzureManagedDomain, creates a no-reply sender username on it, and links both domains to the communicationServices resource.
• Promote the CustomerManaged domain to be the active sender automatically once its DNS verification status reaches Verified. Until then, the fromSenderDomain output stays on the Azure-managed fallback so transactional email keeps flowing through the verification window. The existing SENDER_EMAIL_ADDRESS=no-reply@${communicationService.outputs.fromSenderDomain} wiring on account-api and main-api picks up the new sender on the next container app revision, with no env-var or app-code change.
• Pass the cluster's domainName parameter (already wired to the STAGING_DOMAIN_NAME and PRODUCTION_DOMAIN_NAME GitHub variables and used today for cluster ingress) into the communication-services module so the email sender matches the host the user lands on.
• Extend the existing Show DNS Configuration step in .github/workflows/_deploy-infrastructure.yml to also surface the ACS Email custom-domain DNS records. The step uses the same gating pattern as the cluster-ingress DNS check: silent on first deploy when the resource does not exist, one line on subsequent runs once the domain is fully verified, and a list of TXT and CNAME records to add at the registrar while verification is still pending. While pending, the step also calls az communication email domain initiate-verification for each record still in NotStarted, VerificationFailed, or CancellationRequested (idempotent, required because Azure does not auto-trigger verification when DNS records appear).

Checklist

• I have added tests, or done manual regression tests
• I have updated the documentation, if necessary

[linear]

PP-1194 Add custom email domain to Azure Communication Services