Custom connector: /authorize completes but connection still fails (ofid_9a97d9d128dfa05e)

## Reference ID
`ofid_9a97d9d128dfa05e`

## Server
- MCP server URL: `https://jplfvyxbofpmolfstzhh.supabase.co/functions/v1/mcp`
- Authorization server (Supabase Auth OAuth 2.1, beta): `https://jplfvyxbofpmolfstzhh.supabase.co/auth/v1`
- MCP implementation: `@lovable.dev/mcp-js@0.24.0` running as a Supabase Edge Function
- OAuth client type: confidential (`client_secret_post`), redirect URI `https://claude.ai/api/mcp/auth_callback`

## Symptom
The custom connector's authorization flow (`/authorize`) completes without error in the browser, but the connection in claude.ai still fails with the `ofid_` reference above. No error is surfaced on our OAuth consent screen before or during the redirect.

## Diagnostics already verified (all passing per the troubleshooting checklist)

| Check | Result |
|---|---|
| DNS / public reachability of MCP server | OK |
| No unexpected redirect on MCP URL | OK |
| `401` on unauthenticated MCP request includes `WWW-Authenticate` with `resource_metadata` pointer | OK — `Bearer realm="mcp", resource_metadata="https://jplfvyxbofpmolfstzhh.supabase.co/functions/v1/mcp/.well-known/oauth-protected-resource"` |
| Protected resource metadata (`/functions/v1/mcp/.well-known/oauth-protected-resource`) | OK — `resource` and `authorization_servers` correct |
| Authorization server metadata (`/auth/v1/.well-known/openid-configuration`) | OK — `issuer` matches exactly what the MCP server expects |
| `code_challenge_methods_supported` includes `S256` | OK |
| `token_endpoint_auth_methods_supported` includes `client_secret_post` | OK — matches registered client config |
| Registered redirect URI matches `https://claude.ai/api/mcp/auth_callback` exactly | OK |
| MCP server audience check (`acceptedAudiences: "authenticated"`) matches default Supabase OAuth token `aud` claim | OK (no custom Access Token Hook in use) |

Since every item in the published troubleshooting checklist passes, this looks consistent with the pattern reported in #271 and #620 — the authorization step completes, but claude.ai does not appear to call the token endpoint afterward (based on our reasoning; we don't have direct visibility into claude.ai's internal logs, hence filing this with the reference ID for server-side tracing).

## Request
Could someone trace `ofid_9a97d9d128dfa05e` server-side to confirm whether the token exchange request was made, and if not, why?