Custom connector OAuth fails on reconnect (double /authorize, no callback) despite working via MCP Inspector against the same server

## Summary

Custom MCP connector OAuth fails to complete on every attempt *after* the first successful connection - both reconnecting an existing connector and deleting/recreating it from scratch. Server-side logs and direct protocol testing show the failure is in Claude's client-side OAuth orchestration, not the MCP server.

## Reference IDs (ofid_)

- `ofid_5520e37e67033d7c`
- `ofid_3c9bd795f904e8e0`
- `ofid_c65f7e710e3f93fe`
- `ofid_de08cd87b6473c49`

## Environment

- Custom remote MCP connector, added via the organization admin portal (Team/Enterprise custom connector)
- Auth type: OAuth 2.0, static Client ID supplied in connector settings (DCR was also tried and separately hit an unrelated `POST /register` 400 - worked around by pre-registering a static public client directly against our own `/register` endpoint)
- Server: custom Python (fastmcp-based) OAuth proxy in front of an upstream IdP (Atlassian), deployed on Azure Container Apps
- Tested from both Claude Code (`/mcp` reconnect) and the claude.ai web/app UI - same symptom in both

## Symptom

1. First-ever connection to a newly-added connector succeeds (auth completes, tools list).
2. Every subsequent connection attempt - "Reconnect" in the UI, `/mcp` reconnect in Claude Code, and even deleting the connector entirely and re-adding it fresh - fails with either:
- "Couldn't connect. Taking you back to the desktop app. You can close this tab." (claude.ai-hosted page, browser never reaches the upstream IdP's login screen at all), or
- "Authorization with the MCP server failed. You can check your credentials and permissions."

## Server-side evidence

Our server logs consistently show **two `GET /authorize` requests per connection attempt, ~28-47 seconds apart**, each with a fresh PKCE `code_challenge`/`state`, and in almost every case **no `/oauth/callback` (our upstream IdP callback endpoint) is ever hit** - i.e., the browser never completes the round trip to the upstream IdP and back. This timing is consistent enough across many attempts to suggest a client-side timeout on the initial redirect/page-load that triggers an automatic retry, followed by giving up after the second attempt.

In one attempt, a callback *did* arrive, but referencing a `state`/transaction ID that didn't match any recent `/authorize` call - our server correctly rejected it as an invalid/expired transaction. This is a downstream symptom of the same double-fire pattern (an abandoned browser tab from an earlier attempt completing against an already-superseded transaction), not a separate bug.

## What we ruled out

- **Not a scope/credential issue**: verified with multiple scope configurations, including a minimal reference set already working in production on a sibling connector using the same server codebase.
- **Not a redirect_uri mismatch**: confirmed byte-for-byte match between what's registered and what's sent.
- **Not our server or the upstream IdP**: manually navigating to our server's `/authorize` URL directly in a plain browser tab (bypassing Claude entirely) completes cleanly through the upstream IdP's login/consent screen.
- **Not our server or the upstream IdP (second confirmation)**: [MCP Inspector](https://github.com/modelcontextprotocol/inspector) (`npx @modelcontextprotocol/inspector --server-url --transport http --client-id `), a spec-compliant third-party MCP client, completes the full OAuth flow end-to-end against the identical server, client ID, and scope configuration that Claude fails on.

## Ask

Since a spec-compliant client completes this flow cleanly against our unchanged server, and Claude's client fails consistently and specifically on reconnect (not initial connect), we believe this is a bug in Claude's client-side OAuth handling rather than a server-side issue. Happy to provide full server logs, HAR-equivalent request timing, or a temporary test connector if useful for reproduction.