Implement SEP-985: Align OAuth 2.0 Protected Resource Metadata with RFC 9728

Blocked by: #88

This is a tracking issue for implementing the updated Authorization spec behavior SEP-958

Summary

Update MCP authorization behavior so that clients first honor WWW-Authenticate when present, and fall back to well-known Protected Resource Metadata discovery when it is not.

Needs to implement:

• Client behavior

  • On 401 Unauthorized responses, parse WWW-Authenticate and, if present with resource_metadata, use that URL for protected resource metadata.
  • If the header is absent or missing resource_metadata, fall back to probing /.well-known/oauth-protected-resource.
  • Implement the overall flow:
    1. Attempt the MCP request without a token.
    2. If a 401 Unauthorized is received:
       • If WWW-Authenticate with resource_metadata is present, use it.
       • Otherwise, request /.well-known/oauth-protected-resource.

• Server behavior

  • Servers SHOULD return WWW-Authenticate with resource_metadata when responding with 401 Unauthorized, where feasible.
  • Maintain support for metadata discovery via /.well-known/oauth-protected-resource for environments where header injection is not practical.

• Tests and validation

  • Cover both paths: header-present and header-absent fallback.
  • Validate interoperability with existing deployments that already use WWW-Authenticate.
  • Add regression tests for incremental authorization flows that rely on WWW-Authenticate challenges (e.g. requests that require additional scopes).

Start by resolving the dependency on issue #88, then locate the Kotlin client and server authorization handling for 401 responses and metadata discovery. Add coverage for WWW-Authenticate resource_metadata handling, the well-known fallback, and incremental authorization challenges; done means both discovery paths and existing deployments remain supported.