claude.ai/Cowork completes OAuth authorize successfully but never calls /token — connector stuck on "started but didn't finish"

## Bug: claude.ai / Cowork completes OAuth authorize step successfully but never calls /token — connector stuck on "you started connecting but didn't finish"

**Related to:** #155, #164, #171, #184, #215, #217, #271 — same underlying pattern (OAuth authorize succeeds, token exchange never attempted), still reproducible as of 2026-07-22.

### Environment
- Custom remote MCP server, deployed on Cloudflare Workers, using `@cloudflare/workers-oauth-provider@0.8.2` (latest available).
- Reproduced identically in **both** Claude Desktop (Windows) and claude.ai web.
- Server: `https://nixaj-rag.ajorisan.workers.dev` (MCP endpoint `/mcp`).

### Symptom
1. User clicks "Connect" on the custom connector in Cowork/claude.ai.
2. Browser opens `/authorize` (our server's login page), user submits password.
3. Server responds `302` with a valid `code` + matching `state`, redirecting to `https://claude.ai/api/mcp/auth_callback?code=...&state=...`.
4. Nothing happens after that. Cowork later shows: *"You started connecting to [connector] but didn't finish."*
5. Server-side logs (`wrangler tail`) confirm **zero requests ever reach `/token`** after the redirect, across multiple independent attempts (app + web, cancel-and-retry, fresh connector creation).

### What we ruled out on our own server (exhaustive manual reproduction)
We replayed the entire flow manually via curl, matching the real client's behavior exactly, and it **succeeds every time**:
- Dynamic Client Registration (`POST /register`) — 201, returns `client_id` + `client_secret`.
- Confirmed the real client registers with `token_endpoint_auth_method: "client_secret_post"` (confidential client) — replayed this exact mode.
- `POST /authorize` with the real `client_id` captured from the browser's actual request — `302` with valid code, every time.
- `POST /token` with `client_secret_post` (client_id + client_secret + code_verifier) — **200 OK**, valid access_token + refresh_token returned.

We also found and fixed one real spec violation on our side (`registration_client_uri` was returned as a relative path instead of absolute, per RFC 7591 §3.2.1 — a bug in `@cloudflare/workers-oauth-provider`, still present in the latest 0.8.2). Fixing this did not resolve the issue.

### Conclusion
Since our server completes the entire flow correctly every time we replay it manually — including the exact confidential-client variant the real Claude client uses — but the real client never attempts `POST /token` after a successful `302` redirect, the failure appears to be client-side (claude.ai/Cowork's OAuth callback handling), consistent with the pattern already reported in the linked issues.

### Request
Could someone confirm whether this is the same root cause as the linked issues, and if there's any known workaround or fix timeline?