Bind email authentication to token purpose and verified provider identity #184

Follow-up to #156/#157; source 385e7679fabc60b80cd65cf0a1aa4cdf3d592514, reviewed 2026-10-23. The security inventory records bounded evidence, not deployed-site clearance.

Priority: P2 authentication-boundary work, delivered as separate focused token and OAuth PRs. No live callback or account takeover was attempted.

Evidence:

• Token storage/verification has no purpose field/argument. Login redemption and reset completion use the same verifier; reset issuance uses the same creator. Source establishes no purpose boundary; HTTP cross-use was not exercised.
• OAuth strategies forward email/profile without a required verified-email contract. The shared helper links by existing email or marks a new user verified. Exploitability depends on the provider's actual guarantees; no unverified live provider email was demonstrated.
• Password update changes the hash; the JWT utility has no account/session revision. Reset-session revocation policy needs an explicit contract.

Already fixed: PR #169 enforces single-use, execution-time expiry and inactive-account rejection. The current GraphQL context reloads active account/current role. Do not treat those historical gaps as open.

Acceptance criteria:

• Token PR: persist and require login/reset purpose at issuance and atomic consumption; define safe migration for old untyped links. Add owned SQLite/API cross-purpose negative tests both directions, retaining concurrency/replay/expiry/DB-error coverage.
• Specify reset revocation of old sessions/outstanding links; test the chosen policy on local HTTP and WebSocket authentication using owned active/disabled/reactivated accounts.
• OAuth PR: document each provider's official verified-email contract; require that proof for automatic email linking or use an authenticated explicit linking flow. Preserve provider+subject identity and current-account checks.
• Test missing/unverified/multiple email, existing-account collision, linked subject and disabled-account profiles at helper/callback boundaries with synthetic provider fixtures. Preserve existing-account migration/recovery.

New red/green endpoint results must be recorded before declaring these corrected. No live provider, shared database or token disclosure is needed.