fix(oauth): pin the Claude Code client metadata document

[abnoumaru]

Why

Authenticating the openstatus MCP server from Claude Code fails in the browser:

{"error":"invalid_client","error_description":"Client metadata document responded with HTTP 403"}

claude.ai serves a Cloudflare bot challenge to some datacenter egress (observed on Fly in #2653), which is what KNOWN_CLIENT_DOCUMENTS exists for. That map only carries the Claude web client (mcp-oauth-client-metadata). Claude Code identifies itself with its own document (claude-code-client-metadata), so with nothing stored yet the 403 surfaces as-is.

The new entry is what claude.ai serves at that path, reduced to the fields ClientMetadataDocument reads. The port-less loopback redirect_uris are what claude.ai publishes; matchesRegisteredRedirectUri already matches an ephemeral port against them.

Tests

• The pinned-fallback test iterates every entry, so a mis-typed name or redirect on any pin fails, not only the first.
• Pinned documents bypass parseClientMetadataDocument at runtime; each is now run through it so a hand-copied entry cannot skip the validation a fetched one gets.

Note

Takes effect once api.openstatus.dev ships it. The [oauth/cimd] ... responded with HTTP 403 (cf-mitigated=...) log line from #2653 should show the Claude Code URL in the Fly logs; I cannot see them, so a maintainer's confirmation would be welcome.

[vercel]

@abnoumaru is attempting to deploy a commit to the OpenStatus Team on Vercel.

A member of the Team first needs to authorize it.

[abnoumaru]

Every time a new client document is added, we would need to create a separate pinned entry for it. I realized that dealing with each one this way would just turn into an endless cycle. The root cause is that fetches from Fly's outbound network are being blocked, and this should be fixed by the static egress IPs mentioned in #2653 instead. I'm closing this.