Add JavaScript EP1 Front Door expansion using shared Function infrastructure

[Hou (SciencePotato)]

Summary

• Add Setup-EppFrontDoor.ps1 to expand a supported existing Linux JavaScript EP1 EPP deployment into two or three new regional copies behind Front Door Standard.
• Reuse setup/infra/resources.bicep with optional typed Front Door settings. The existing single-region path keeps its defaults.
• Copy the source package, add the reviewed opt-in readiness handler, replicate certificate material through encrypted Key Vault backups, and pin regional key references. Preserve the original source Function, application registration, caller permissions, and policy.
• Add source/configuration guards, same-subscription/geography validation, scoped ingress, immutable package checks, atomic resumable checkpoints, and fail-closed target ingress recovery.
• Use one entry point: Setup-EppFrontDoor.ps1 deploys; -Verify runs secure-token evaluation without changing Azure resources. Update onboarding with the tested scope and manual alternatives.

Scope and limits

• JavaScript, Linux EP1, v2 application-ID audiences, private managed-identity run-from-package sources only.
• Supports explicit evaluation-only mode and API-key setup profiles. OAuth federation, FC1, Python, and .NET expansion are rejected for provider-enabled automation rather than silently misconfigured.
• Policy activation stays manual. Source is retained outside the new origin group for rollback.
• Live verification covered evaluation-only deployment, not provider-secret replication, live SMS/voice, or new failover benchmarks. Existing measured transition failures remain documented.

Validation

• 25 targeted JavaScript readiness/SendOtp tests passed.
• PowerShell guards, ZIP augmentation, atomic state backup, geography/ownership validation, protected restore, and verifier endpoint checks passed; existing certificate regression suite passed.
• main.bicep, frontdoor.bicep, and frontdoor-regions.bicep compile.
• A new isolated Central US + West US 2 expansion deployed from an existing source. A stalled certificate restore client was stopped; target ingress closed and the unchanged checkpoint/package resumed successfully using the timeout-bounded restore path.
• The new Front Door initially returned404 during publication. Initial directed tests were checked against regional logs rather than accepted at face value; a stronger secondary test stopped the new primary and allowed propagation. Each origin then passed10 encrypted-evaluation/authentication/malformed-request checks, and all origins were restored.
• Direct-origin spoof/no-spoof requests blocked403; final readiness200 and anonymous SendOtp401. Source package and key references unchanged.
• 195 local documentation links/anchors validated; PowerShell examples parse; git diff --check passed.

No production authentication policy changes were made. The prior experimental worktree remains separate and untouched.

Simplification

• Reduced the PR from 22 to 20 changed files and from 9 to 7 new files.
• One PowerShell entry point for deployment and verification; one PowerShell test suite.
• Existing deployment functions and Bicep are unchanged. The moved verification statements are preserved. Consolidated tests, 195 links/anchors, and updated command examples pass.
• No Azure redeployment was performed for this structural refactor.

Further consolidation

• Now 19 changed files (originally 22). Removed the unnecessary contract-wording change.
• Replaced manual HttpClient/token marshalling with PowerShell secure-token HTTPS support; reused the existing ARM operator helper.
• Condensed the expansion guide from 407 to 377 lines. Runtime helper is 540 lines, down from 550.
• Added offline request/decryption tests covering all five verification checks and wrong-nonce failures. Total diff lines increased slightly because these tests were added, despite shorter runtime code and docs.
• Setup and certificate tests, 195 links/anchors, and command syntax checks pass. No Azure resource changes or new live deployment were made.