Expose invitation email binding through the Aspire API

[woksin]

Added

• WithInviteEmailBinding on the Aspire builder, binding an invitation to the address it was issued to so only the invited recipient can redeem it (Expose invitation email binding through the Aspire API #85)

[woksin]

Reviewer context (kept out of the body so it stays release-note clean).

Why a separate extension and not a parameter. Adding a trailing optional emailClaim to either existing WithInvite overload is binary breaking — C# bakes the default into the call site, so already-compiled AppHosts would hit MissingMethodException. The usual escape hatch fails too: a same-name overload differing only by the trailing optional argument makes every existing omitting call ambiguous (CS0121). Composing after either overload also means one method covers both invite configuration shapes. WithSignedInvitationAttestations is the in-repo precedent for exactly this shape.

The unreachable-feature finding. InvitationAttestationConfigurationValidator.cs:71-74 requires Invite.EmailClaim unconditionally when attestations are enabled, and the guard is genuinely reached: the validator returns early only when invite?.Attestation is null (:23-28), WithSignedInvitationAttestations binds Invite.Attestation to non-null, it is registered as IValidateOptions<Configuration.AuthProxy> (InvitesServiceCollectionExtensions.cs:25), and IngressExtensions.cs:49-53 calls ValidateOnStart() on that same options type. TenantClaim is required identically but was already exposed through Aspire; EmailClaim was the only one with no typed route.

Gate. Debug and Release, --no-incremental -warnaserror: 0 errors, 0 warnings. Aspire.Specs 68 passed / 0 failed (66 before, +2).

Mutation evidence, run independently of the implementer, with an assertion that the mutation actually applied before testing:

• Emitted key changed to ...__Invite__EmailClaimMUTANT → and_a_claim_is_named RED, dying at its own assertion indexer (KeyNotFoundException on the real key), not in Because(). SPECIFIC. and_no_claim_is_named correctly stayed green.
• Guard if (!string.IsNullOrEmpty(...)) removed → and_no_claim_is_named RED, and_a_claim_is_named green. SPECIFIC.
• Restore verified by shasum -a 256 (not diff): 742e21d6...272ebd before and after, then rebuilt and re-ran to confirm GREEN.

Worth recording: the implementer's first attempt at the second mutation reported a survivor that was a false negative — its perl -0pi pattern silently matched nothing, so the file was never mutated. Any mutation harness should assert the pattern matched exactly once and compare pre/post digests before running the spec.

Not verified: no AppHost was actually booted, so the startup-validation failure is established from the four code paths above rather than observed. Nothing asserts it end to end; a spec composing both builders and running the real validator over the bound configuration would close that, but it spans the Aspire and AuthProxy projects and was outside this change.