Custom connector: OAuth completes (token minted, audience/scope/PKCE all correct) but claude.ai never calls the MCP endpoint

## Summary

Remote MCP custom connector (added by URL). OAuth completes — the `/token` endpoint returns 200 and mints an access token — but claude.ai (web/desktop) then shows **"Authorization with the MCP server failed"** and, per full server-side request logging, **never sends any authenticated request (GET or POST) to the MCP endpoint** with that token. The **same server connects and works from Claude Code (CLI)** — it's specifically the hosted claude.ai path that obtains the token and then stops.

Matches the recurring pattern in #171 / #315 (which links several more with the same symptom: #184, #280, #313, #314).

## Verified server-side (instrumented every OAuth + MCP path)

- Token mints with the correct RFC 8707 audience = our canonical MCP URL (the exact `resource` Claude sends).
- Scope matches exactly: Claude requests the four scopes we advertise in `scopes_supported`; we grant and return the identical set.
- PKCE `S256` verified; `resource` validated; `/token` responds in ~270 ms.
- A manually-forged, correctly-signed token **works** at the MCP endpoint (returns a valid `initialize`) — the resource server accepts valid tokens; Claude simply never presents one.
- No different-host redirect on the MCP URL; discovery documents (RFC 9728 / RFC 8414) are public and correct.
- Tried the access token as a 3-segment HS256 JWT (vs an opaque 2-segment token) — no change.

## Sequence (from our logs, a single connect)

1. `POST /mcp` (no bearer) → `401` + `WWW-Authenticate: Bearer resource_metadata=...` (discovery probe). ✓
2. `POST /oauth/authorize` → authorization code issued; requested scope and resource are correct. ✓
3. `POST /oauth/token` → **200, token minted, correct audience.** ✓
4. …then **zero** requests to `/mcp` from Claude. Nothing further arrives. → "Authorization with the MCP server failed".

## Details

- OAuth 2.1, CIMD. Client id: `https://claude.ai/oauth/mcp-oauth-client-metadata`
- Works: Claude Code (CLI). Fails: claude.ai hosted (web/desktop).
- Reference IDs (ofid): `ofid_f7202d36970a9813`, `ofid_586b4aeac5116f40`, `ofid_5c07e59050da53dc`

## Ask

Can you trace these ofids to see why the hosted client aborts after the token exchange without ever calling the MCP endpoint?