Agent Sessions sidebar: per-session status freezes for Copilot CLI sessions (both directions); mark-as-read and rename inert

- Copilot Chat Extension Version: 0.58.0 (bundled `copilot-chat`)
- VS Code Version: 1.130.0 (1b6a188127eeaf9194f945eb6eb89a657e93c54c)
- OS Version: macOS 26.5.2 (25F84)
- Feature: Agent Sessions view (Copilot CLI sessions provider)
- Selected model: Claude Fable 5
- Logs: excerpts inline below

## Summary

In one window, the Agent Sessions sidebar's **per-session status froze** at a
point in time (~11:25–11:35 local) and never updated again, while the sessions
themselves kept running fine. Both directions of wrongness at once:

- An **idle** session kept showing the in-progress indicator (blue dots), with
its subtitle stuck on a tool step ("Read cspell-probe.log") that had
completed ~40 minutes earlier. **"Mark as read" had no effect** — the stale
in-progress state kept re-asserting the unread dot.
- **Rename was dead too**: attempting to rename some of the stuck entries had
no effect (pre-restart) — the frozen items' action surface, not just their
status/read-state, was affected.
- A session that was **genuinely mid-turn** (blocked on a pending tool
permission approval) showed **no progress indicator at all** — its entry was
frozen at "idle, 48 mins ago", from before its current turn started. The
permission prompt itself was never seen either (not found in the chat pane;
possibly never rendered) — the session sat silently wedged.

No cross-attribution: each entry displayed its *own* session's stale snapshot.
It looks like a single freeze of the per-item status stream, not mixed-up
sessions.

## Evidence

CLI-side state on disk was **clean and live** throughout — the staleness is in
the extension's view of it:

1. **Idle-but-shown-busy session** (`116212c2…`): its `events.jsonl` shows
balanced pairs across the whole period — 36/36
`tool.execution_start`/`complete`, every turn closed, and a proper
`session.shutdown` at the end of each user turn. The tool step named in the
stuck subtitle completed at ~11:35 (the freeze onset).
2. **Busy-but-shown-idle session** (`9ac390d9…`): its `events.jsonl` ends with
`assistant.turn_start` → 3× `tool.execution_start` →
`permission.requested` at 11:50, with 9 `permission.requested` vs 8
`permission.completed` — i.e. genuinely in-turn, awaiting approval, started
~25 min *after* the freeze — and never got a progress indicator.
3. **The provider's enumeration kept running**: `GitHub Copilot Chat.log` for
that window shows `listSessions took` entries continuously through and
after the freeze window (no gap, 11:00→12:30, dozens per 10-min bucket),
and store size here is small (~93 sessions; `listSessions` is fast). So
this is not the O(N) enumeration stall of #327021 — the list refreshed;
the **per-item status/read-state** is what froze.
4. No correlated `[error]` entries in the extension log at freeze onset (only
unrelated GitServiceImpl noise about an untitled buffer).
5. Both sessions (and a third, healthy-and-active one) were owned by the same
extension-host process (single `inuse..lock` holder), same window.

## Steps to reproduce

Not deterministic; observed state documented above. Setup that produced it:

1. One window (workspace `~/git`) with several Copilot CLI sessions: one
actively working, others conversational with pauses between turns.
2. Use the sessions over ~an hour (turns, tool calls, permission prompts).
3. Observe the sidebar freeze per-session status at some point: idle sessions
stuck "in progress" (mark-as-read ineffective), a later-started real turn
never showing progress.

## Expected

- Sidebar status tracks each session's actual state (in progress / awaiting
approval / idle).
- "Mark as read" clears the unread dot for a session that is not running.
- A session blocked on a permission approval is surfaced as such — "awaiting
approval" is more actionable than a generic spinner in the chat pane and no
indicator in the list.

## Notes

- Possibly related but distinct: #327021 (same provider, but that's full-store
enumeration cost; enumeration demonstrably kept running here), #326599
(anecdotal "stuck sessions", no state evidence).
- Happy to provide the two sessions' `events.jsonl` files and the window's
extension log privately if useful.
- **Restarting VS Code cleared the stale state** (confirmed ~12:50): after the
restart the sidebar rendered current status again. Workaround exists, but the
freeze is silent — until restart, the list actively misreports session state.