[BUG] Desktop (Linux): spawn_task sessions still start without claude_desktop_config.json MCP servers; attach happens on UI focus, tools reach the model only on the next queued turn (re: #67432)

Related: #67432 (closed by inactivity bot), #90061 (in-flight turn ignores MCP pushes)

## Environment

- Claude Desktop 1.49585.0 (Linux, `claude-desktop` package)
- Claude Code (Code tab) 2.1.260
- OS: Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic
- 7 local stdio MCP servers configured in `~/.config/Claude/claude_desktop_config.json`

## Summary

This is the bug in #67432, which the inactivity bot closed as not planned on 2026-07-21. It still reproduces, and not only on macOS. A session started from a `spawn_task` chip begins its first turn with only the app-internal MCP servers. ToolSearch for any configured server returns "No matching deferred tools found".

The desktop logs show where it goes wrong:

1. For chip-spawned sessions, `CCD start-timing` reports `mcp_count=8`/`9` (internal servers only). Normally started sessions report `mcp_count=15`/`16`.
2. The configured servers are attached (`LocalSessions.replaceEnabledMcpTools` + `reconcileServers`) only when the spawned session is focused in the UI (`LocalSessions.setFocusedSession`), not when it starts.
3. Even after that attach, the model gets the `deferred_tools_delta` only at the next queued user turn. A message steered into the running turn does not carry it.

## Evidence (main.log)

| Launch path | `mcp_count` at init | First `replaceEnabledMcpTools` after start |
|---|---|---|
| Normal (5 sessions, 09-05 to 09-10) | 15–16 (`init_mcp=connected:15/16`) | same second to +2 s |
| spawn_task chip A | 9 | +2 min 6 s |
| spawn_task chip B | 9 | +2 s |
| spawn_task chip C | 8 | +37 s (same second as `setFocusedSession`) |

Session C timeline (UTC, from main.log and the session's transcript `.jsonl`):

- 20:18:49 `Spawned-task started` → session starts; `CCD start-timing ... mcp_count=8 ... init_mcp=connected:8/pending:0/failed:0`
- 20:18:50 first-turn `deferred_tools_delta`: only `ccd_directory`, `ccd_session_mgmt`, `mcp-registry`, `scheduled-tasks` (plus other internal servers)
- 20:19:26 `setFocusedSession` → `replaceEnabledMcpTools toolCount=243` → `reconcileServers created=[<7 local servers>, ...] total=15`
- 20:19:45 ToolSearch for a configured server → no match
- 20:20:10 user message steered into the running turn → **no** `deferred_tools_delta` attached
- ~20:20:27 ToolSearch for the same server → "No matching deferred tools found"
- 20:28:29 next queued user message → `deferred_tools_delta` adds all 7 local servers; tools work from this turn

The MCP servers themselves were healthy the whole time. They had been connected since 20:07 and answered `tools/list` in about 200 ms, per `mcp-server-.log`.

## Reproduction

1. Configure one or more stdio MCP servers in `claude_desktop_config.json`.
2. In a Code-tab session, have Claude call `spawn_task`; click the chip.
3. In the spawned session's first turn, ToolSearch for a configured server finds nothing.
4. Focus the session and steer a message into the running turn: still nothing.
5. After that turn ends, send another message: the tools are available.

## Expected

Chip-spawned sessions should attach the same MCP servers at start as normally started or scheduled sessions. At minimum, a delta arriving mid-turn should be delivered with the next steered message or tool result.

## Impact

Workflows that depend on an MCP memory server at session start (a mandatory recall in `CLAUDE.md`) silently skip it in every spawned task. As #67432's comments note, spawning several tasks means visiting each one to kick its tools loose.

Reproduce the issue from a Code-tab session using spawn_task and inspect main.log alongside the spawned session's transcript .jsonl. Trace the startup path against LocalSessions.setFocusedSession, replaceEnabledMcpTools, and reconcileServers, comparing the logged MCP counts and deferred_tools_delta timing. Done means spawned sessions receive configured MCP servers on start, and any mid-turn delta is available by the next steered message or tool result.

Escrito por el modelo de indexación a partir del texto del issue.