MCP tool manifest for a project-scoped remote connector doesn't refresh across --continue or a fresh launch

**What happened**

A remote streamable-HTTP MCP server (project-scoped — connected in-session but not listed in `/mcp`'s server panel, which showed 21 user/claude.ai connectors, none matching this one) had two new tools deployed to it (`simulate_delete_quote`, `delete_quote`, added to an existing, already-connected server).

Tool discovery (`ToolSearch` with exact-name `select:` queries) returned "No matching deferred tools found" for both new tools, across four separate attempts:
1. The original session, immediately after the deploy.
2. After checking `/mcp` — the connector wasn't listed there at all (21 servers shown: 2 "User MCPs" + 19 claude.ai connectors), so no reconnect action was available for it.
3. After `claude --continue` (same session resumed in a new process).
4. After a fully fresh `claude` launch with no resume flag at all (new process, no restored session state).

None of the four picked up the new tools.

**Root cause narrowed down**

Calling the same server directly over raw HTTP — bypassing the CLI's MCP client entirely, using the same Bearer credential the CLI's own connector uses — returned both tools correctly on `tools/list` and `tools/call` on the very first attempt. This confirms:
- The deployed server was correctly serving the new tools the whole time.
- The staleness is entirely on the CLI/client side.
- Whatever caches this connector's tool manifest is not invalidated by session resume (`--continue`) or by a brand-new process launch — which is surprising, since a fresh process launch would normally be expected to re-run the MCP handshake from scratch.

The connector's absence from `/mcp`'s own server listing (point 2 above) suggests it may be registered/managed through a different path than user-managed MCP servers, which may be where the caching that survives a process restart lives.

**Repro**

1. Have an active session connected to a project-scoped remote MCP server.
2. Deploy a new tool to that server (add a tool registration, redeploy).
3. From the same session, try to discover/call the new tool. Confirmed stale.
4. Try `claude --continue`. Still stale.
5. Try a fresh `claude` launch (no flags). Still stale.
6. Call the server directly over HTTP with the same auth the CLI uses. Tool is there immediately.

**Environment**

- CLI version: v2.1.247 (from the fresh-launch startup banner)
- Server: a Supabase Edge Function acting as an MCP server (streamable-HTTP transport), confirmed `ACTIVE` and serving the correct, current source at the time of every failed discovery attempt.

**Impact**

A user has no way to get newly-deployed tools on an already-connected project-scoped MCP server to become visible short of bypassing the CLI's own MCP client and hitting the server directly with raw HTTP — which most users can't do, and which shouldn't be necessary given `/mcp` didn't even offer a reconnect path for this connector.

No repository files or tests are named. Start by reproducing the project-scoped remote MCP connection and compare tool discovery after the original session, `claude --continue`, and a fresh `claude` launch; inspect the MCP connection and manifest-caching path, using `/mcp`, `ToolSearch`, and raw `tools/list` as comparison points. Done means newly deployed tools become discoverable without bypassing the CLI.

Vom Indexierungsmodell aus dem Issue-Text verfasst.