Remote MCP connector never invoked in Claude Desktop Chat sessions - works on iOS same account; Settings shows Connected with tools; zero Chat-session traffic reaches the server

### What happened?

### Summary
A remote OAuth MCP connector (Streamable HTTP, hosted on Cloudflare Workers) does not have its tools invoked in Claude Desktop (macOS) Chat sessions, despite Settings > Connectors showing it fully Connected with all tools listed and set to "Always allow". The identical connector, same account, works correctly on Claude for iOS. Server-side request logging proves Desktop Chat sessions send zero requests to the server, while iOS sessions do. The failure is silent - no error, no ofid_ reference.

### Environment
Claude Desktop (macOS), version 1.19367.0 (1a5be1), build 2026-07-07
Connector: remote MCP server, OAuth 2.0 + PKCE, Streamable HTTP, Cloudflare Workers
Same Anthropic account across Desktop and iOS; Desktop Chat tab

### What did you expect to happen?

### Expected behaviour
When a Chat session needs the connector's tools, Desktop should invoke the remote server (initialize / tools/list / tools/call), matching documented cross-surface behaviour.

### Actual behaviour
Desktop Chat never contacts the server. Tools do not surface to the model in Chat, with no error shown - silent failure, no reference ID.

### Steps to reproduce

1. Add a remote OAuth MCP connector to Claude Desktop; complete OAuth. Settings > Connectors shows it Connected with all tools listed and permitted.
2. In a Desktop Chat, prompt Claude to use one of the connector's tools.
3. Observe: tools never surface; model reports them unavailable. Not cleared by full Cmd-Q restart + new conversation.
4. Trigger the same tool from Claude iOS (same account) as a control.

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell

```

### Additional context

### Evidence (server-side request tail, times BST)
- Desktop Chat trigger at 13:02:18 - zero requests reached the server; monitored continuously through 13:05:47 including delayed-retry checks. Nothing arrived.
- iOS trigger ~13:05:45 (control) - 9 successful POST calls, 13:05:37-13:05:47, all 200 OK, matching the expected multi-step tool chain. A working client's traffic appears immediately.
- Separate burst 13:00:18-23 - 6 successful POST calls plus a token exchange, from Desktop's Settings > Connectors page re-validating the connection. This confirms Desktop's OAuth/Settings code path can authenticate and reach the server; the Chat conversation path does not. Two code paths on the same client; only Chat is broken.

**Local Desktop logs** (~/Library/Logs/Claude/main.log, mcp.log): no Chat-tab connector activity. Only connector references are [CCD] Code-tab replaceRemoteMcpServers calls (separate path). Consistent with Desktop Chat tool-fetching being brokered server-side, leaving no local trail.

### Server health (ruled out as cause)
- Unauthenticated request returns correct 401 with RFC 9728 WWW-Authenticate metadata
- Both .well-known OAuth discovery endpoints spec-compliant
- Dynamic client registration returns 201
- Server tool list exactly matches what Desktop's connector page displays
- The iOS positive control proves the full authenticated handshake succeeds end-to-end against this same endpoint

### Diagnosis
Connector, OAuth, and tool list are healthy and reachable - proven by both the iOS control and Desktop's own Settings-page validation reaching the server. The failure is isolated to Claude Desktop's Chat session path, which never invokes the connector. This is upstream of the MCP server, in Anthropic's Desktop Chat connector brokering.

### Related issues
Same "Connected, tools listed, never surfaced" family as #476 and the #470-474 cluster. Distinct failure point: in #476 the broker reaches the server and completes tool calls (tools just don't reach the model); here the Desktop Chat broker sends zero requests to the server, while the same account's iOS broker reaches it normally. The iOS-working / Desktop-Chat-silent same-account control isolates the fault to Desktop Chat's broker dispatch, one step earlier than #476.