Release v2.6.1

Summary

Follow-up to the invite trust-boundary hardening (#55). That change added Invite.EmailClaim with a default of email, which meant gateway email-binding enforcement turned on automatically for any deployment whose invite tokens already carry an email claim — a policy change imposed on framework consumers by upgrade alone, and one that could reject invites that were previously accepted.

This makes the gateway enforcement opt-in while keeping the useful, low-risk half unconditional: the authenticating account's verified email is still always forwarded to the exchange endpoint, so an app can enforce the invited-email/authenticated-email binding itself. Deployments that want AuthProxy to reject a mismatched account at the gateway now enable it explicitly by setting Invite.EmailClaim.

Phase-2 token re-validation (the signature/issuer/audience/lifetime re-check from #55) is unaffected and stays on.

Changed

• Invite.EmailClaim now defaults to empty, so gateway email-binding enforcement is off by default. Set it (for example to email) to require the authenticated account's verified email to match the invited email at the Phase-2 exchange. The verified email is forwarded to the exchange endpoint regardless of this setting, so the backend can still enforce the binding itself.