OAuth2 OP readiness M3: Spec conformance and security fixes #1252

Milestone 3 of the OAuth2/OIDC provider production-readiness roadmap (audit: doc/src/contributor/oauth2-production-readiness.md, findings F-C1..C4, F-D2..D7, F-B7).

Problem

Standard OIDC clients cannot interoperate with the OP as-is, and three security defects were found during the audit:

• Discovery is inaccurate (well_known.rs:105-123): grant_types_supported lists "device_code" instead of the RFC 8628 URN, omits the token-exchange URN, device_authorization_endpoint, code_challenge_methods_supported, none/client_secret_post auth methods, and several claims.
• Token responses lack Cache-Control: no-store / Pragma: no-cache (RFC 6749 §5.1 MUST).
• Device-code polling at /token has no rate limiter at all; a Pending poll is a Raft write.
• Device-grant redemption skips the client enabled/deleted_at/domain_id check.
• Issuer and verification_uri derive from the Host header when public_endpoint is unset; cookie Secure depends only on proxy headers.
• Successful human-grant audit events use build_initiator_unknown() even though the user is known.
• No RFC 9207 iss in authorization responses; no RFC 8252 loopback-port wildcard for native apps.
• token_endpoint_auth_method and require_pkce are stored but not enforced.

Exit criteria

• A stock RP library (openidconnect crate) completes discovery and both the code and device flows with no manual overrides.
• Regression tests exist for each of the three security defects.
• All /token and HTML responses carry Cache-Control: no-store.

This milestone is small and should land before M2/M4 regardless of appetite for those.