[FEATURE] VSCode session lifecycle: pin + active/done state + grouping (umbrella for #63842/#66202/#64468/#76089)

Problem Statement

The VSCode extension's session list is flat and reverse-chronological — every session is an undifferentiated entry supporting only rename / resume / remove. There's no way to pin a session, no way to record whether a session is active (in-flight, will resume) or done (finished), and no way to group or filter the list by that state.

This scales badly. For anyone running several concurrent pieces of work — a common pattern with git worktrees and parallel branches (a feature, a review, a spike, a long-running investigation) — a dozen sessions across worktrees becomes a memory game: long-lived reference sessions sink below newer noise, finished work looks identical to in-flight work, and I re-open the wrong session or re-read to find where I left off. It directly hurts day-to-day UX/DX.

Several existing issues each request one slice of this. This issue proposes treating them as one coherent session-lifecycle model rather than four disconnected features, because the value compounds when they ship together. Related existing requests:

• #63842 — pin / bookmark sessions
• #66202 — mark a session completed / dismiss it
• #64468 — manually override session status + a Closed/Archived state
• #76089 — per-session status indicator (colored dot) in the VSCode session list

Proposed Solution

A lightweight session-state model surfaced in the VSCode sidebar. Three independent pieces, each useful alone, compounding together:

1. Pin / unpin (cf. #63842) — pinned sessions sort to the top and stay there regardless of recency; a hover action mirroring the existing rename/remove affordances.
2. State: Active / Done (cf. #66202, #64468) — a per-session status the user sets. Active = in-flight work I'll resume (visually prominent); Done = finished (de-emphasized or collapsed). Could default sensibly, e.g. a session idle for N days is offered as "mark done".
3. Grouping / filtering (cf. #76089 for the visual indicator) — group the sidebar by state (Pinned / Active / Done) or a filter toggle to hide Done. This is where a long list becomes navigable.

Ideal UX: pinned sessions stay at top; Active sessions are the working set; Done sessions collapse out of the way. State persists per-project across restarts and is visible in the session switcher, not just the sidebar.

Pinning solves persistence, Active/Done solves lifecycle, grouping solves scale.

Alternative Solutions

• Rename-as-convention (prefix names with [DONE]/⭐): possible today, but manual, unsorted, and doesn't collapse or filter — a workaround, not a solution.
• Shipping the four linked issues piecemeal: each helps, but the workflow win comes from having pin + active/done + grouping together; a status dot (#76089) without a settable state, or a state without pinning, only gets partway.
• Full PM metadata (due dates, boards, assignees): explicitly not wanted — too heavy. The ask is deliberately minimal: pin + active/done + group.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

(Targets the VSCode extension sidebar specifically; the form has no dedicated IDE-extension category, so this is the closest fit.)

Use Case Example

I typically have 4–8 sessions open across separate git worktrees: an active feature branch, a PR I'm reviewing, a spike, and a multi-day investigation I return to. With today's flat list I lose track of which session maps to which task, and the investigation sinks below newer noise. With pinning I'd keep the investigation at top; with active/done I'd collapse the finished feature and PR-review sessions, leaving just what I'm working right now; with grouping the sidebar stays legible at 8+ sessions.

Additional Context

Applies to the Claude Code VSCode extension. Current session UI is rename / resume / remove plus a status dot on the spark icon (blue = permission pending, orange = finished while hidden) — no pin, no settable state, no archive/grouping. Filing as an umbrella that ties #63842 / #66202 / #64468 / #76089 into a single lifecycle model; happy to have it linked/closed as duplicate if maintainers prefer to track the pieces separately.