fix(workos): serve OAuth AS metadata (CIMD/DCR) instead of OIDC discovery

[piersonmarks]

The WorkOS plugin's /.well-known/oauth-authorization-server route mirrors AuthKit's
OpenID Connect discovery document (/.well-known/openid-configuration), which omits
client_id_metadata_document_supported (CIMD), registration_endpoint (DCR) and
code_challenge_methods_supported (PKCE). AuthKit advertises those only at its RFC 8414
OAuth Authorization Server Metadata endpoint. As a result, MCP clients (e.g. ChatGPT)
report CIMD and DCR as unsupported even when they are enabled in the WorkOS dashboard.

This PR:

• Fetches /.well-known/oauth-authorization-server (RFC 8414) so the advertised
  metadata carries the CIMD/DCR/PKCE fields.
• Adds a 5s AbortSignal.timeout on the upstream fetch so a slow or stalled AuthKit
  cannot hang the request and pin a slot.
• Falls back to the existing static metadata on any fetch error instead of returning a
  500, so discovery stays available through transient upstream blips.

Verified against a live AuthKit domain that /.well-known/oauth-authorization-server
contains client_id_metadata_document_supported: true and registration_endpoint
while /.well-known/openid-configuration contains neither.

Optional follow-up (not included to keep the diff tight): the
OAuthAuthorizationServerMetadata type does not declare registration_endpoint or
client_id_metadata_document_supported. It is not required for correctness (the success
path passes the fetched document through verbatim), but adding them as optional fields
would make the type accurately model AuthKit's response.

Tracked as #602.

[vercel]

@piersonmarks is attempting to deploy a commit to the xmcp Team on Vercel.

A member of the Team first needs to authorize it.

[0xKoller]

Hey @piersonmarks! Thanks for contributing!
Before doing a deeper review, could you upload an example of this fix working? That way I can confirm it’s the proper solution.

[0xKoller]

@piersonmarks Hey!

Any updates on this?