docs(security): 2.4.0 at-rest encryption key advisory + --encryption-key

[lakhansamani]

Documents the security advisory and breaking change from authorizerdev/authorizer#742.

• New: security advisory section — affected versions 2.2.1-rc.2 → 2.4.0-rc.13, RSA/ECDSA only, with an affected/not-affected table and remediation steps.
• Corrected: the existing OTP and TOTP at rest and Key rotation sections still said --jwt-secret keys the encryption. It doesn't any more, and the runtime error message they quoted was stale.
• New: --encryption-key reference in server-config, with the three-state behaviour table (set / falls back / refuses to start).

Also advises setting --encryption-key explicitly even on HMAC installs: while it and --jwt-secret are the same value, rotating the JWT secret — routine on its own — silently destroys every TOTP enrolment, because the at-rest key has no re-encryption path.

Verified with npm run build; new anchors resolve.

[netlify]

✅ Deploy Preview for authorizerdev-docs ready!

Name	Link
🔨 Latest commit	cc25d48
🔍 Latest deploy log	https://app.netlify.com/projects/authorizerdev-docs/deploys/6a75fcd2c18ebb0008b91ba3
😎 Deploy Preview	https://deploy-preview-79--authorizerdev-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lakhansamani]

Pushed a427095 — the rest of the 2.4.0 documentation, on top of this PR's encryption-key advisory (both touch server-config.md, so stacking here avoids a conflict).

New page: Email Verification Contract

docs/core/email-verification-contract.md, ported from the server repo's docs/email-verification-contract.md and added to the sidebar after core/email.

Adapted rather than copied: dropped the test-matrix section and the internal Go file references (verify_otp.go, login.go), since those are implementation detail rather than operator-facing. Kept the per-provider signal table, the three connection classes, the nOAuth explanation, the recovery routes, and the dashboard operator actions.

Breaking changes documented

--enable-email-verification with no SMTP is now fatal at boot. Documented in server-config.md with the exact condition — all three of --smtp-host, --smtp-port > 0 and --smtp-sender-email, because setting only the host still fails.

Social logins now require provider attestation of the email. New section under the social-provider list covering why OAuth proves nothing about an address, the Entra specifics (no email_verified on v2, mutable email, multi-tenant endpoints signing with global keys), the three fixes, and that --oauth-allow-unverified-provider-email narrows rather than disables the check.

_delete_user takes id, not email — updated in all four places that documented the old signature:

File	What changed
core/graphql-api.md	request-param table + admonition
core/rest-api.md	request-body table + admonition
core/grpc.md	description + why field 1 is reserved rather than reused
contributing.md	the copy-pasteable example mutation, which still passed an email

--microsoft-allowed-tenants added to the Microsoft flag list.

Two deliberate non-changes

• versioned_docs/version-1.x untouched. delete_user really did take an email in v1; retroactively editing a released version's docs would make them wrong.
• Nothing from PR refactor(verify-email): one decision core for both implementations authorizer#752 is documented. That PR merged into security/2.4.0-audit-part-2 minutes after that branch had already merged to main, so its content is not in main. I verified internal/service/verify_email_core.go does not exist on main before deciding this.

I did verify the claims I did port. The 30-minute link TTL and "resend mints a fresh request when none exists" are both real in main (internal/token/verification_token.go:15, internal/service/resend_verify_email.go:99) rather than taken on trust from the source doc.

Verified

npm run build exits 0 with zero broken-link warnings — worth stating explicitly because this site sets onBrokenLinks: 'warn', so a broken link would not have failed the build. I checked the built HTML directly: the new page renders at /core/email-verification-contract with its content intact, and the cross-link from server-config resolves to that path.