Custom connector works in Routines but chat never sends `initialize` — tools never bind in interactive chat

### What happened?

A custom remote MCP connector ("flow.mcp") is fully connected and authorized. Its tools load and run correctly when invoked from a **Routine** in the same project. In **interactive chat**, the same connector's tools never become available — and the server receives no `initialize` request from the chat session at all.

This is not a connector add/OAuth failure — the connection succeeds and works via Routines. The problem is the interactive chat path never opening an MCP session against an already-working connector.

Observed:
- In chat, tool discovery returns zero tools from this connector; only another connector (Gmail) surfaces. The target tool (`hello_world`) is never callable.
- Server request inspector shows **no `initialize` / `tools/list` originating from the chat session.** Starting a brand-new chat produces no new MCP session on the server.
- The same connector, same account, same token: **Routine runs perform a full `initialize` + `tools/list` and receive all tools, HTTP 200.** The client identifies as `Claude-User` (clientInfo `claude-ai` / `Anthropic/Toolbox`).

Ruled out with evidence:
- Server health / transport — Routine sessions succeed end-to-end; a manual curl `initialize` reaches the server and returns the full tool list.
- OAuth / token — full flow captured server-side (`/authorize` → `/token`, valid Bearer, `expires_in` 2592000); Routine sessions authenticate fine. The only 401s in logs are unauthenticated manual probes and the expected discovery probe that triggers OAuth.
- ngrok URL rotation — live `public_url` matches the connector URL exactly.
- ngrok browser interstitial — only triggers on browser User-Agents; `Claude-User` requests pass it cleanly.
- Per-conversation toggle — ON from session start, never changed.
- Fresh context — reproduces identically in a brand-new chat.

Distinction from existing reports: related "OAuth completes but claude.ai never sends `initialize`" issues (#291, #214, #227) fail at connector **add** time ("Couldn't reach" / "Not connected"). This differs — the connector is fully connected and demonstrably functional via Routines; only the **interactive chat** path fails to initialize it. The routine-works / chat-doesn't split on one connected connector is the key signal.

### What did you expect to happen?

With the connector enabled for the conversation, an interactive chat should open an MCP session (`initialize` → `tools/list`) against the server at conversation start and bind its tools — the same way Routine sessions on the identical connector already do — making the connector's tools callable in chat.

### Steps to reproduce

1. Add and authorize a custom remote MCP connector (Streamable HTTP, OAuth 2.1). Confirm it shows connected.
2. Enable it for a new chat via the connectors toggle; confirm the toggle is ON.
3. Send any message in the chat. Observe on the server's request inspector: no `initialize` from the chat session; the connector's tools are unavailable in chat (tool discovery returns nothing from this connector).
4. From the same project, create or run a Routine that uses the same connector. Observe: the server receives a full `initialize` + `tools/list`, returns all tools (HTTP 200), and the tools work.

Result: identical connector, identical account/token — Routine initializes and binds tools; interactive chat never contacts the server.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

flow.mcp — self-hosted, uvicorn, Streamable HTTP (MCP 2025-11-25), OAuth 2.1 Bearer, exposed via ngrok. Server verified healthy: manual `initialize` returns full capabilities + tool list; Routine sessions succeed end-to-end.

### Error messages or logs

```shell
No client-facing error is shown in chat — the failure is silent (tools simply absent).

Server side, the only 401s are (a) unauthenticated manual curl probes and (b) the expected OAuth discovery probe:

HTTP/2 401
www-authenticate: Bearer error="invalid_token", error_description="Authentication required"

No 401 (and no request of any kind) from a `Claude-User` chat session — the chat session never contacts the server.

Contrast — a successful Routine session (from server request inspector):
POST /mcp initialize → 200 (serverInfo: flow.mcp)
POST /mcp notifications/initialized → 202
POST /mcp tools/list → 200 (full tool set incl. hello_world)
User-Agent: Claude-User clientInfo: claude-ai / Anthropic/Toolbox
```

### Additional context

- Reproduced on Claude Opus 4.8 and across multiple fresh chats in the same project.
- The connector was fully reconnected (OAuth re-authorized) shortly before the failing chats; Routine invocations after that reconnect succeeded, chat invocations did not.
- Minor spec note (likely unrelated to this bug, but flagged for completeness): the server returns 404 on `/.well-known/oauth-protected-resource` and `/.well-known/oauth-protected-resource/mcp` (RFC 9728); the client falls back to `/.well-known/oauth-authorization-server` (200) and OAuth still completes. Gmail (a first-party connector) binds in the same chat sessions without issue, so protected-resource metadata does not appear to be the cause.

Evidence (redacted — secrets and host removed):
Successful ROUTINE session (from ngrok inspector):
12:25:31 POST /mcp initialize → 200 (serverInfo: flow.mcp)
12:25:32 POST /mcp notifications/initialized → 202
12:25:32 POST /mcp tools/list → 200 (full tool set incl. hello_world)
User-Agent: Claude-User

Interactive CHAT session (new chat, same connector, toggle ON):

Attachment: