MCP tool discovery silently blocks for 10 minutes when server returns a mismatched response id

When an MCP server returns a tools/list response with a non-matching id,
gemini-cli correctly ignores it (per JSON-RPC 2.0) but then waits exactly
600 seconds before sending notifications/cancelled and giving up.

During this window the CLI is completely silent — no spinner, no warning,
no partial tool list. The user sees a frozen terminal.

Captured with mcp-scope (wire capture of the full session):

```
04:40:32 c2s tools/list id:1
04:40:32 s2c response id:9999 ← wrong id, correctly ignored
04:50:32 c2s notifications/cancelled requestId:1 "Request timed out"
[10 minutes of silence between lines 2 and 3]
```

mcp-scope check output:
```
[ERROR] line 6: response for unknown request id=9999
[WARN] line 5: unmatched request id=1 (no response in capture)
```
Expected: Short timeout (5–10s) with a visible error: "MCP server probe-server failed to respond to tools/list — skipping"
Actual: 600s silent hang, then disconnect with no user-visible message

Why it matters: Any slow or misbehaving MCP server — including servers with the wrong-id bug fixed in googleapis/mcp-toolbox#3332 — will cause gemini-cli to silently block tool
discovery for 10 minutes on every startup.

gemini-cli version: 0.46.0
Captured with: mcp-scope (https://github.com/SSanju/mcp-scope)

Start by locating the MCP tools/list request and timeout handling in gemini-cli, then reproduce the mismatched-response-id case using the mcp-scope capture details from the issue. Verify that discovery stops after 5–10 seconds and displays the stated failure message instead of remaining silent for 600 seconds.

Written by the indexing model from the issue text.