VS Code extension: tab silently attached to a different session, no user action

## Summary

A single, continuously-open Claude Code tab in the VS Code extension silently became attached to a different underlying session, with no action taken by me to close, reopen, or switch anything. This caused real confusion: I asked the assistant to do something, it (from its perspective) had no record of a change that had actually been made moments earlier in "the same conversation," and we spent a long time trying to reconstruct what had happened before finding the second session file.

## Environment

- Claude Code VS Code extension, version 2.1.261
- macOS (Darwin 25.6.0)
- Workspace: `/Users/julielegendre/mgnl-docs`

## Timeline (from the two session JSONL files under `~/.claude/projects/-Users-julielegendre-mgnl-docs/`)

- Session A: `fc0340b7-32d4-4463-a5e7-7fd2e1926902` — active from 2026-09-15 14:39 UTC, last activity before the gap ~2026-09-15 15:00 UTC.
- Session B: `f868bcbd-64ac-40f9-aa0e-dc28d882fb01` — a separate, pre-existing session (history going back to 2026-09-12), active again 2026-09-16 07:38–08:23 UTC, working on the same repo. It made a real commit (`git commit`, hash `1a6297a`) at 08:14:35 UTC.
- Session B's last activity: 08:23:20 UTC.
- Session A resumes: 08:26:32 UTC — 3 minutes later.

Both sessions share identical `entrypoint: claude-vscode`, `version: 2.1.261`, and `cwd`. I did not close the tab, open a new one, or otherwise take any action that should have changed which session was active. From my side this read as one uninterrupted conversation; the assistant's later inspection of its own transcript showed no gap, error, or restart marker in session A's log around that boundary, and no crash indicators in session B's log either.

## Impact

The assistant (working from session A) had no memory of work actually done in session B — including a real commit to the branch we were both working on. When I said "we did this together," the assistant initially couldn't find any evidence of that in its own session and it took considerable back-and-forth (and me insisting) before it located the other session's transcript file on disk and confirmed the commit had, in fact, been made by "the same tab," just under a different session ID.

## What I'd like investigated

What can cause a VS Code Claude Code tab to become attached to a different session ID than the one it started with, without the user closing/reopening the tab or explicitly switching sessions? Whether that's an extension-host restart, a reconnect-to-stale-session bug, or something else, there was no user-visible indication that it had happened.

## Suggested improvement

If a tab's active session ever changes underneath it, surface that to the user directly (e.g., a system message noting the session ID changed), rather than continuing as if nothing happened.

Start by comparing the two session JSONL files under ~/.claude/projects/-Users/julielegendre-mgnl-docs/ around the reported 08:23–08:26 UTC boundary, then trace the VS Code extension's session reconnect or restoration path. Done means identifying how the active session ID can change without user action and defining a user-visible indication when it does.

Written by the indexing model from the issue text.