feat: support private_key_jwt for CIMD clients

## Summary

Support `private_key_jwt` client authentication for clients identified by a Client ID Metadata Document.

## Current behavior

CIMD support accepts only `token_endpoint_auth_method: "none"`. Documents that advertise both `none` and `private_key_jwt` can work because the provider selects `none`, but a client that requires `private_key_jwt` cannot complete authorization code exchange.

This is not a core MCP compliance blocker because the MCP specification makes `private_key_jwt` optional. It is useful for clients that want stronger authentication than an unauthenticated public client.

## Acceptance criteria

- Parse and validate the client's `jwks` or `jwks_uri` metadata according to the CIMD draft.
- Authenticate token endpoint requests using `private_key_jwt`.
- Validate assertion issuer, subject, audience, signature, expiration, and unique identifier/replay constraints.
- Apply SSRF protections to remotely fetched JWKS documents.
- Advertise `private_key_jwt` only when the complete token-endpoint path is supported.
- Add positive and negative tests for key rotation, invalid audience, expiry, replay, unknown keys, malformed assertions, and SSRF-sensitive URLs.
- Document how this interacts with the `global_fetch_strictly_public` compatibility flag.

## References

- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents
- https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00
- https://datatracker.ietf.org/doc/html/rfc7523