[BUG] VS Code extension: remote session from another machine shows "Couldn't load earlier messages" / "New messages start a new conversation", and each sent message silently forks a NEW local session

Environment

• Claude Code CLI: 2.1.251 (originating machine, DAVOR-DESKTOP); secondary machine version unknown (same auto-update channel, presumed 2.1.x)
• VS Code extension: anthropic.claude-code 2.1.251
• OS: Windows 10 Pro (both machines)
• Sessions run under a custom CLAUDE_CONFIG_DIR (secondary-account setup, %USERPROFILE%\.claude-team2); both the originating terminal session and the connecting VS Code extension use the same custom config dir. Untested whether the default ~/.claude config dir is also affected.

Describe the bug
Opening a remote-control session that was started on a different machine in the VS Code extension loads no history at all: the view shows "Couldn't load earlier messages" and "New messages start a new conversation". Worse, sending a message does not error — it silently creates a brand-new local session in the current workspace folder (with its own fresh bridge session), so the message never reaches the original session. Repeated attempts left 4 such "zombie" sessions in the workspace.

Steps to reproduce

1. Machine A: start an interactive session with remote control enabled (remoteControlAtStartup: true), under a custom CLAUDE_CONFIG_DIR, and exchange several messages.
2. Machine B: open VS Code (extension running under the same custom CLAUDE_CONFIG_DIR), open that session from the sessions list.
3. Observe: no history loads — "Couldn't load earlier messages" / "New messages start a new conversation".
4. Send a message → a new local session is created in the current workspace folder; the original session on Machine A never receives it.

Expected behavior
The extension attaches to the existing remote session (full history + live two-way sync), as claude.ai/code does — confirmed working: the same session opened in the browser shows full history and two-way messaging.

Actual behavior
No history is fetched, and each send forks a new local conversation. Transcript forensics on the affected machine confirm the mechanism: the extension-created session file (entrypoint: "claude-vscode") begins with its own newly minted bridge-session record (bridgeSessionId: cse_…, lastSequenceNum: 0) instead of attaching to the original session's existing bridge id — i.e., it falls back to "new local session + new bridge" rather than resuming the remote one. The silent fork is the damaging part: messages appear sent but land in a dead-end session.

Additional context

• Original session's transcript lives only on the originating machine (<config-dir>/projects/...jsonl), but the data clearly exists server-side since claude.ai/code renders it fully.
• Possibly related to #26908 / #41269 (resume: undefined → new session), but here the session does open a UI and accepts input, making the failure silent.