Duplicate claude --resume processes accumulate per-message in Agents window, causing turn to complete but UI to stay stuck on "Processing"

Environment
- VS Code: `1.135.0` (commit `08d4889f9ec4a1685d257b9b95de036c8e1ce1e5`), Stable
- Remote: WSL2 (Ubuntu 24.04), Windows host
- Claude Agent SDK (`@anthropic-ai/claude-agent-sdk-linux-x64`): `0.3.220`
- `agentHost` extension host running via VS Code's built-in Agent/Chat sessions feature (not a marketplace chat extension)
- Model backend: Bedrock-hosted Claude (via `claude` CLI, `--permission-mode bypassPermissions`)

## Summary
When sending consecutive messages into the same agent chat session over a working span of ~30+ minutes, the chat UI eventually stops showing new agent output/status (looks permanently "thinking"/stuck), while the underlying agent turn has actually completed successfully. Inspecting the host process list shows **multiple `claude` CLI processes concurrently resuming the exact same session id**, and `agentHost.log` shows a `sendMessage failed ... Canceled: Canceled` + `truncateChat` pair each time this happens.

The only currently-known workaround is a full `wsl --shutdown`, which kills all other running dev processes in the WSL instance as collateral damage.

## Evidence

### 1. Multiple live processes resuming the same session
At the time of investigation, `ps` showed 4 separate `claude` CLI processes all launched with `--resume=`, ages ranging from ~13 to ~43 minutes old, all still consuming CPU:

```
PID 5166 etimes=2586s --resume=
PID 8283 etimes=1809s --resume= --resume-session-at=
PID 11108 etimes=764s --resume=
PID 11117 etimes=764s --resume=
```

Each of these was still actively producing output (visible via `/proc//fd` open sockets + steady CPU%), i.e. none were hung — they were all independently live and working against the *same* session transcript.

### 2. Each new user message spawns a new resume process instead of reusing/cleanly closing the previous one
Every time a new message was sent into the chat while a previous `claude` resume process for that session was still alive, `agentHost.log` recorded this pair of lines:

```
[error] [AgentSideEffects] sendMessage failed for session=ahp-chat://.../: code=undefined, message=Canceled: Canceled, type=Canceled Canceled
...
[info] [Claude:] truncateChat kept [0..] (anchor=)
...
[info] [Claude] session : resume rebuild agent=(none)
```

This pattern recurred 4 times across a single chat session (observed at roughly 13, 16, 26, and 43 minutes into the session), each one correlating with a newly spawned `claude --resume=` process that was never torn down — leaving the previous one running in the background, orphaned from the UI.

### 3. The agent turn actually completes; the UI just never reflects it
Reading the on-disk session transcript (`~/.claude/projects/.../.jsonl`) directly confirmed the most recent assistant message had `"stop_reason": "end_turn"` and contained a complete, well-formed multi-paragraph response ending in a question to the user — i.e. the agent was not stuck at all, it had finished normally. The chat UI in VS Code, however, continued showing no new content/status, consistent with the UI having subscribed to (or being blocked by) a stale/orphaned process rather than the one that actually produced the final message.

## Steps to reproduce (best known)
1. Open an agent/Claude chat session in VS Code (Bedrock-backed Claude, WSL2 remote).
2. Have a long-running conversation (30+ min) involving multiple tool calls / sub-agent dispatches.
3. Periodically send follow-up messages while the agent may still be mid-turn or shortly after a turn completes.
4. After several such messages, the chat UI stops updating (looks stuck "thinking"), even though:
- `ps aux | grep claude` shows multiple processes with identical `--resume=` still running and consuming CPU.
- `agentHost.log` shows a `sendMessage failed ... Canceled: Canceled` immediately followed by a `truncateChat` / `resume rebuild` for that session id, once per "new" process spawned.
5. Confirm via the on-disk `~/.claude/projects/**/.jsonl` transcript that the latest assistant message has `stop_reason: end_turn` and is a complete response — the turn is not actually hung.

## Workaround
`wsl --shutdown` from Windows forcibly kills all WSL processes (including the orphaned `claude` resume processes), after which the chat UI reconnects properly on next launch. This also kills unrelated dev servers running in the same WSL instance, which is a heavy-handed workaround for what looks like a chat-session/process-lifecycle bug.

## Expected behavior
Sending a new message into an existing agent chat session should not spawn an additional concurrent `claude --resume` process against the same session id while a previous one is still alive; the previous process should be cleanly terminated/reused, and the UI should always be wired to the currently-live process's output stream so completed turns are reflected without requiring an environment-level restart.