fix(auth): harden one-time link recovery

[StringKe]

Summary

• bind one-time-link recovery to the originating browser History entry so stale sessionStorage credentials are never reused on unrelated navigation
• clear terminally rejected credentials while retaining retryable failures, and render branded localized recovery UI instead of raw API JSON
• add low-cardinality server-side rejection reasons for Magic Link verification without logging credentials, URLs, user identifiers, or provider payloads
• align authentication and operations design docs plus Lingui catalogs

Root cause

The scrubbed credential was retained under a route-wide sessionStorage key without proving that the current History entry originated from that link. A later visit could therefore recover a stale one-time credential. Terminal errors also shared UI behavior with transient failures, which either left stale state behind or prevented a safe retry. Existing structured logs identified only the public error code, not the failed verification stage.

User impact

Magic Link, email verification, and password reset pages now keep credentials only for same-entry reload recovery. Expired or invalid credentials transition to localized recovery states, transient failures expose a retry action, and users never see raw JSON from these Hosted UI flows.

Validation

• pnpm check

• pnpm test

• focused Core regression suite: 40 tests

• pnpm --filter @xid-kit/server typecheck

• pnpm run security:secret-scan

• git diff --check

• No secrets, .env files, real tokens, private keys, or real tenant data in the diff

• Commit includes DCO sign-off