MCP OAuth (claude mcp login) ignores RFC 9728 protected-resource-metadata discovery — always targets resource origin for /authorize and /oauth2/token

Environment: Claude Code 2.1.206 (also reproduced on 2.1.202), macOS.

Summary: For an HTTP-transport MCP server registered with claude mcp add --transport http <name> <url> --client-id <id> --callback-port <port>, claude mcp login <name> does not follow the OAuth 2.0 Protected Resource Metadata discovery chain (RFC 9728). It instead assumes the MCP server's own origin is also the OAuth authorization server, which breaks any deployment where the resource server and authorization server are on different hosts (e.g., a resource behind a custom API gateway/service, with a separate Cognito/Okta/Auth0 authorization server).

Reproduction:

1. Resource server returns a spec-compliant 401 challenge:

``
WWW-Authenticate: Bearer resource_metadata="https://resource.example.com/some/path/.well-known/oauth-protected-resource"
``

1. That metadata URL correctly returns:

``json
{"authorization_servers": ["https://issuer.example.com/some-id"], "resource": "https://resource.example.com/some/path"}
``

1. The issuer's own .well-known/openid-configuration correctly returns a real authorization_endpoint and token_endpoint on a different host than the resource server (this is the standard shape for e.g. AWS Cognito fronting an API).
2. Run claude mcp login <name>.

Expected: Claude Code fetches the resource_metadata document from the challenge, follows authorization_servers[0], fetches that issuer's .well-known/openid-configuration, and uses the authorization_endpoint/token_endpoint found there.

Actual: Claude Code constructs <resource-origin>/authorize?... directly (ignoring discovery entirely) and, after the user manually completes login against the correct authorization server and pastes back the redirect URL, it then also tries to redeem the code at <resource-origin>/oauth2/token, instead of the token endpoint discovered from the issuer metadata. Both requests 404 with the resource server's generic "invalid path" error, since the resource origin has no such endpoints — only the discovered authorization server does.

Impact: Any MCP server that correctly implements the MCP Authorization spec's resource/authorization-server separation (a very common pattern: API gateway as resource server, dedicated IdP as AS) cannot be authenticated via claude mcp login at all.