OAuth completes, token 200, then zero authenticated MCP requests — persists after all #136 fixes (protocol 2025-11-25 / CORS / no-store); Cloudflare Workers

### Summary

The "silent abandon after token" behaviour tracked in #136 / #254 **still reproduces in July 2026** on Claude Desktop (macOS) — **even after applying every server-side fix documented as the resolution in those threads.** OAuth completes end-to-end, `POST /oauth/token` returns `200` with a valid token, and then Claude makes **zero** further requests to the MCP endpoint. The user sees "Could not connect to the server / connector issue."

I'm filing fresh because #136 is closed as resolved-via-protocol-version, but that fix does **not** cover this case — posting in case it's a residual or variant bug.

### Environment
- **Server:** self-hosted MCP on Cloudflare Workers (Hono), Streamable HTTP transport, custom domain, behind Cloudflare Access with a path-scoped Bypass on the MCP + OAuth + `/.well-known` routes.
- **Client:** Claude Desktop (macOS); OAuth consent opened in Chrome (system default).

### Full server-side trace (wrangler tail — one attempt)
```
POST /api/me/mcp initialize (auth=none, Accept: application/json, text/event-stream) → 200
GET /.well-known/oauth-protected-resource/api/me/mcp → 200
GET /.well-known/oauth-authorization-server → 200
POST /api/me/oauth/register → 201 (DCR)
GET /api/me/oauth/authorize (consent page) → 200
POST /api/me/oauth/authorize (after Approve) → 302 → https://claude.ai/api/mcp/auth_callback?code=…&state=…
POST /api/me/oauth/token → 200 (access_token + token_type=Bearer + expires_in + scope=mcp)
⋮ ZERO subsequent requests to /api/me/mcp from Claude after this point ⋮
```

### Fixes already applied from the #136/#254 threads — none resolved it
- `initialize` **negotiates `protocolVersion: 2025-11-25`** (the #136 resolution). Verified: client sends `2025-11-25`, server echoes `2025-11-25`. (This was already the case before we "fixed" it, since we echo the client's version — which is why the protocol fix changes nothing for us.)
- **Streamable HTTP** transport (not legacy SSE); responds with JSON or SSE per `Accept`, returns `Mcp-Session-Id`.
- **Absolute** `resource_metadata`; `issuer` == origin; PRM `resource` == the MCP URL; ASM `token_endpoint_auth_methods_supported: ["none"]`.
- **RFC 6749 §5.1** `Cache-Control: no-store` + `Pragma: no-cache` on the token response; `expires_in` present.
- **CORS + `OPTIONS` preflight** on the MCP endpoint, `Access-Control-Expose-Headers: Mcp-Session-Id`.
- **PKCE S256** verified server-side; DCR returns `token_endpoint_auth_method: none`.

### Proof the server + token are correct
The **identical** endpoint connects flawlessly with a **bearer token**:
- `npx mcp-remote --header "Authorization: Bearer "` → `Connected … Proxy established successfully`.
- Raw `curl` → `initialize`, `tools/list`, and `tools/call` all succeed (correct JSON-RPC, negotiated `2025-11-25`).

So the server speaks MCP correctly and the issued token works. **The only thing that never happens is claude.ai making the authenticated MCP request after its own successful token exchange.** This is entirely within Claude's OAuth-callback → MCP-connect handoff.

### Workaround (for others hitting this)
We shipped a local `.mcpb` desktop extension bundling a tiny dependency-free stdio↔HTTPS bridge (runs on Claude Desktop's bundled Node, bearer token in `mcp_config.env`). It connects **first try, every time** — which further confirms the server and token are fine; the gap is purely the native-connector OAuth path.

### Ask
Is #136 genuinely resolved, or is there a residual/variant where a fully spec-compliant AS still gets abandoned after `token` 200? Happy to provide an `ofid` or run any capture that helps.