Support OAuth client ID metadata documents (CIMD) for MCP clients

[khvn26]

Our OAuth authorisation server currently identifies MCP clients via anonymous dynamic client registration (RFC 7591). This works, but every connector setup mints a new Application row, there is no way to rotate or manage registrations (we do not implement RFC 7592), and the client name shown on the consent screen is self-asserted.

Client ID metadata documents solve all three: the client_id is an HTTPS URL on the client's own domain (e.g. https://claude.ai/oauth/claude-code-client-metadata), and the authorisation server fetches the client metadata from that URL. We stop littering Application rows, and consent screen name is anchored to a domain the client operator controls. This is the direction Anthropic is taking: Claude Code already uses a CIMD client_id and falls back to DCR only when the server does not advertise support.

Non-goals: RFC 7592 registration management; replacing DCR.

Acceptance criteria

• HTTPS URL client_ids at the authorise and token endpoints are accepted and validated.
• Only public DNS names are accepted, and unreachable URLs don't break the endpoints.
• client_id_metadata_document_supported: true is advertised in the RFC 8414 metadata.
• CIMD documents declaring a secret-based method (client_secret_basic, client_secret_post) are rejected as invalid — no registration step exists to distribute a secret.
• CIMD documents declaring private_key_jwt are rejected as not yet implemented.
• Documents omitting token_endpoint_auth_method are treated as none.
• CIMD rejections are logged and counted, like DCR rejections.
• DCR is still available for clients that do not implement CIMD (i.e., Cursor).