OAuth client SSRF filter checks host strings, not resolved addresses

Summary

From 2.0.0 until 3.7.0, the rmcp OAuth client decided whether it may fetch an authorization server's metadata URL by inspecting only the host string. It rejected literal loopback, private and link-local IP addresses and known cloud metadata hostnames, but it did not resolve other hostnames. A hostname that resolves to an internal address passed the check.

A malicious MCP server can return protected-resource metadata that names an authorization server whose hostname resolves to an internal address. The client then sends GET requests to that address during discovery.

The same release fixes two related bypasses:

- Bracketed IPv6 literals such as `http://[::1]:6379/` were not recognized as internal, because the check kept the brackets from the URL host. - `token_endpoint` and `registration_endpoint` from authorization server metadata were not checked at all, and token requests follow redirects. A malicious authorization server could make the client send POST requests to an internal address.

The impact is client-side SSRF. Responses are not returned to the attacker directly. Unauthenticated internal HTTP services are reachable. Cloud metadata endpoints that require headers or IMDSv2 are largely unaffected.

The flaw was corrected in 3.7.0. `AuthorizationManager::new` now builds its HTTP client with a DNS resolver that applies the address policy to every resolved address, and checks every IP-literal URL and followed redirect against the same policy. Loopback and private addresses are allowed only when the MCP server's own URL names one of that class. Deployments that reach their authorization server through a hostname that resolves to a private address should use `AuthorizationManager::new_allowing_private_addresses`.

Clients supplied through `new_with_oauth_http_client` are not covered by the resolved-address checks. Such clients must enforce their own outbound address policy.