feat: 3 phase discovery for oauth metadata discovery

[jpmcb]

Motivation and Context

There are a wide variety of OAuth providers that don't necessarily adhere to strict RFC 8414 paths for metadata discover. For example, Okta provides their OAuth servers with a oauth2/{id} path. So your server will look like:

https://my-org.okta.com/oauth2/abc123

where its metadata is discoverable like so:

❯ curl https://my-org.okta.com/oauth2/abc123/.well-known/oauth-authorization-server

{
  "issuer": "https://my-org.okta.com/oauth2/abc123",
  "authorization_endpoint": "https://my-org.okta.com/oauth2/abc123/v1/authorize",
  "token_endpoint": "https://my-org.okta.com/oauth2/abc123/v1/token",

  // etc. etc. etc.
}

This change implements a 3 phased metadata discovery fallback:

1. First try to use the exact metadata URL as is
2. Try RFC 8414 path-aware discovery
3. Try root level discovery

(Note: this also captures some fixes my editor automatically made for alot of trailing whitespace in auth.test.ts)

How Has This Been Tested?

Unit tests

Breaking Changes

Fully backwards compatible, no breaking changes, existing tests pass.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Fixes: #744
Related: modelcontextprotocol/inspector#634

[katesclau]

Got a similar implementation here #748, with a different priority over the calls.