VSCode: keep in-progress issues in the Backlog with the builder's state icon

[amrmelsayed]

Summary

Today the Backlog view removes any issue that already has an active builder (spawnableBacklog filters on hasBuilder). This follow-up to #926 proposes keeping those issues in the Backlog and rendering the builder's state icon on their row — the same bell (blocked) / comment-discussion (idle) / circle-filled (active) vocabulary used on builder rows — instead of dropping them.

Spun out of the #926 plan-gate discussion to keep #926 scoped to the area-header roll-up icon. The mechanics are easy; the reason this is its own issue is the product/semantics decisions below.

Motivation

• Dissolves VSCode: area-header roll-up icons in backlog & builders views #926's known limitation. An area whose only open issue is being built currently vanishes from the Backlog (the issue is filtered out → no area header). Keeping the issue visible keeps the area's header and gives the engineer the full picture.
• Makes the area-header roll-up a literal roll-up. VSCode: area-header roll-up icons in backlog & builders views #926's green header dot reflects a builder on an issue you can't see. If in-progress issues stay, the header dot matches a green child row you can actually see and click.
• One place for "open work + live status," rather than splitting "spawnable" (Backlog) from "in flight" (Builders).

Mechanics (the easy part)

backlog.ts's makeRow already has the backlog item and the full data (incl. data.builders). Look up the row's builder by issue id (data.builders.find(b => b.issueId === item.id)), classify with the existing isBlocked / isIdleWaiting logic, and set the matching icon. Falls back to today's issues/account icon when no builder.

Decisions to make (why this isn't in #926)

1. Double-spawn guard. spawnableBacklog removes built issues specifically so you can't spawn a second builder from the Backlog. If they stay, the row's Spawn Builder context action must be hidden — give those rows a distinct contextValue (e.g. backlog-item-building) and gate the menu when clause on it.
2. Count / filter semantics. The title Backlog (N), the mine-only filter, and visibleBacklogCount all build on spawnableBacklog. Decide whether in-progress issues count toward (N) and whether "Backlog" still means "spawnable work" or becomes "all open issues with status."
3. Dashboard parity. spawnableBacklog's doc comment states it deliberately mirrors the web dashboard's BacklogList (items.filter(i => !i.hasBuilder)) so the two surfaces show the same available-work set. Keeping built issues in VSCode only would diverge them — decide whether to also update the dashboard or accept the divergence.
4. Builders-view duplication. An in-progress issue would then appear, with the same icon, in both the Backlog and Builders trees. Confirm that's acceptable (or intended).

Relevant files

• packages/vscode/src/views/backlog-filter.ts — spawnableBacklog (the filter to relax)
• packages/vscode/src/views/backlog.ts — makeRow (icon lookup), orderedSpawnable, counts
• packages/vscode/src/views/backlog-tree-item.ts — row contextValue for the spawn guard
• packages/codev/src/agent-farm/servers/overview.ts — hasBuilder / activeBuilderIssues projection (matched by issue id)

Relationship to #926

Builds on #926 (area-header roll-up icon). #926 ships the binary header dot with built issues still filtered out; this issue revisits the filtering itself.