vscode: accordion shouldn't affect builder area-group headers, and group expansion state should be ephemeral

[amrmelsayed]

Problem

The Builders tree's accordion (expand one builder → collapse the others, extension.ts:291-328) is implemented via VSCode's workbench.actions.treeView.codev.builders.collapseAll, which is the bluntest available API: it collapses every expandable node in the tree, not just builder rows. That includes the area-group headers (VSCODE (4), TOWER (3), etc.).

Combined with the area-group expansion persistence (views/area-group-expansion.ts:46-58, wired in extension.ts:262-263), this has two unintended consequences:

1. Other area groups visibly collapse when you expand any single builder. The accordion's reveal(builder, { expand: 3 }) walks the parent chain so the group containing the clicked builder re-expands — but all other groups stay collapsed.

2. That collapse is persisted to workspaceState under codev.buildersGroupExpansion. persistAreaGroupExpansion listens to onDidCollapseElement with no source check, so it can't tell "user clicked a chevron" from "collapseAll fired programmatically" and writes false for every group that just collapsed. The collapse survives reloads — the user has to manually re-expand each group on every restart until they next interact with each one.

Principle

Accordion is a builder-row behavior, not a tree-wide behavior. Expanding one builder should collapse the other builder rows (so you don't have diffs from multiple worktrees on screen at once). It should not touch area-group headers — those are a navigation aid the user controls explicitly.

Per-area-group expansion in Builders is ephemeral. Active builders are short-lived (hours, maybe a day or two), the set churns constantly, and a reviewer working with builders generally wants to see all of them. Persisting "you collapsed VSCODE last Tuesday" across reloads is overkill and currently mostly serves to surface the accordion bug above. Default to expanded on every session; let the user collapse during a session if they want, and let that state die on reload.

Proposed scope

1. Decouple accordion from area-group headers. Concrete approach left to plan-approval — VSCode has no "collapse only these elements" API, so options include: (a) snapshot the area-group expansion map before collapseAll, restore via reveal after; (b) replace collapseAll with iterating known-expanded builders and revealing them in a way that collapses them individually (if possible); (c) some other arrangement. The principle is what's load-bearing; the mechanism is a plan-phase design call.

2. Drop persistence of per-area-group expansion in the Builders view only. Remove the persistAreaGroupExpansion(buildersView, ...) wiring at extension.ts:262-263 and delete the persisted codev.buildersGroupExpansion key on first load (one-shot cleanup so dead state doesn't linger forever). BuildersProvider.expansion becomes in-memory only.

3. Leave Backlog's persistence alone. The Backlog view has a different lifecycle — long-lived backlog items, hundreds of issues, users actively curating which areas they care about. The same persistence mechanism is appropriate there. (extension.ts:268-269 stays.)

Acceptance

• Expanding a builder collapses other builder rows but not area-group headers (any group, any state).
• No codev.buildersGroupExpansion writes from any code path. Stored value (if present from a prior install) is deleted on activation, once.
• On every fresh session, every Builders area group renders expanded by default. User-collapsed groups stay collapsed for the rest of that session.
• After reload (Developer: Reload Window), all Builders groups are expanded again regardless of what they were before.
• Backlog's group-expansion persistence behavior is unchanged — verify by collapsing a Backlog group, reloading, confirming it's still collapsed.

Out of scope

• Reworking how the accordion is exposed to users (the title-bar toggle / codev.buildersAutoCollapse config stays as-is).
• Backlog-view group persistence (separate concern, different lifecycle, intentionally kept).
• File-tree folder expansion within builders (already correctly handled via expand: 3 on reveal).

Why this lives in one issue

The two fixes are joined at the hip: even if you only do #1 (decouple accordion from groups), persistence is still wrong because we shouldn't persist ephemeral nav state in this view at all. And if you only do #2 (drop persistence), the accordion still visibly collapses other groups for the duration of the session — annoying every time you click. Both together is the coherent fix.