Plan indicator leaks across conversations after headless session switches

Describe the bug

When the IDE switches one headless Copilot CLI process between two conversations that share the same repository, worktree, and branch, the plan indicator/path can remain bound to the previously active conversation.

Observed result:

• Conversation A had a physical per-session plan.md.
• Conversation B had no plan.md and an empty per-session task database.
• While B was active, the IDE displayed A's session-specific ...\A\plan.md beside B.
• The UI for A simultaneously claimed that A did not have a plan.
• Nothing had moved on disk: A's plan remained under A's session-state directory and B's directory had no plan.

The CLI/backend session state was correctly isolated; the visible conversation-to-plan association was reversed/stale.

Affected version

Copilot IDE 1.12.1
Copilot CLI backend 1.0.71
VS Code 1.130.0
Windows x64

Steps to reproduce the behavior

1. Open two IDE conversations for the same repository/worktree/branch.
2. In conversation A, enter plan mode and create/update plan.md.
3. Leave conversation B without a plan.
4. Switch repeatedly between A and B so the IDE resumes both through the same headless CLI process.
5. Observe the plan indicator/path after B becomes active.

In the affected run, sanitized debug logs showed the same process repeatedly alternating:

resume A -> Workspace initialized A
resume B -> Workspace initialized B
resume A -> Workspace initialized A
resume B -> Workspace initialized B

After the final Workspace initialized B, B displayed A's plan path. The local IDE metadata cache contained A but had no entry for B.

Expected behavior

Plan state must be keyed and rendered strictly by conversation/session ID:

• Activating B must clear A's plan indicator before B is rendered.
• A conversation without plan.md must never inherit a plan based on shared cwd, repository, branch, process, or prior active state.
• Session resume/switch should atomically update conversation content, plan state, task state, and metadata-cache ownership.
• If the active session lacks a cache entry, the UI should query that session or show no plan rather than retaining the previous session's plan.

Additional context

The backend evidence rules out a filesystem move or shared SQL state: each conversation retained its own session directory/database, and the active session's injected context pointed at the correct session folder. This appears to be stale IDE/session-controller state during rapid headless session switching.

The IDE package points to a separate private repository that is not accessible to either configured GitHub identity, so this is filed against the CLI/session tracker for routing. No private logs or conversation content are attached.

Trace headless session resume and switch handling around the alternating “Workspace initialized A/B” events, then inspect how plan state and metadata-cache ownership are associated with the active conversation. Done means switching to a session without plan.md clears the prior indicator and keeps plan, task, content, and cache state keyed to that session.