Support a canonical CIMD client ID for outbound OAuth

[tandemloop]

Problem

McpMux currently passes None as the client metadata URL when it creates an outbound AuthorizationSession, so even when an authorization server advertises client_id_metadata_document_supported, the flow falls back to Dynamic Client Registration.

That prevents installation of remote MCP servers that intentionally disable open DCR and approve exact public client identities. The current DCR request contains client_name, a loopback redirect URI, standard grant/response types, and scopes, but no verifiable software_id or client metadata URL. A client name such as McpMux is not an authentication boundary.

This blocks a CareClinic Health Tracker McpMux registry submission. CareClinic uses an exact-client OAuth policy and will not enable impersonable open DCR.

Proposed Solution

Publish a McpMux-controlled HTTPS Client ID Metadata Document and pass its URL as client_metadata_url when the remote authorization server advertises client_id_metadata_document_supported: true.

The metadata should identify McpMux and register the existing native-app callback pattern, http://127.0.0.1:{port}/oauth2redirect. The authorization server can then validate the exact HTTPS client ID document plus the loopback host and path while allowing the RFC 8252 ephemeral port.

Keep the current DCR flow as the fallback for servers that do not advertise CIMD support.

Alternatives Considered

• Adding a static client ID or secret to each public server definition. This is not suitable for a native public client and the current registry schema has no such field.
• Allowing DCR based on client_name and callback shape. Any client can copy those values, so this weakens an exact-client policy.
• Publishing the server listing before authentication works. This would create a broken one-click install path.

Additional Context

The rmcp SDK version used by McpMux already accepts an optional client metadata URL in AuthorizationSession::new; the current outbound pool call supplies None. McpMux already uses the correct loopback callback shape and PKCE.