Surface multiple architects in Tower dashboard + VS Code extension + afx status

[waleedkadous]

Context

PR #757 (spec #755) shipped builder→architect message routing for the sibling-architect pattern. The routing primitive works: Tower supports multiple architect terminals per workspace, each with a stable name, and afx send architect from a builder routes back to its spawning architect specifically.

But spec #755 deliberately kept the user-facing surface scalar: /api/state.architect returns one architect (main or first registered), the dashboard shows one Architect tab, and the VS Code Workspace view shows one architect entry. Architects added via afx workspace add-architect exist in Tower but have no clickable way to access their terminal from the standard UX.

This makes the feature half-shipped — humans can't actually drive the sibling-architect pattern through the dashboard or VS Code today; they have to know the terminal ID from the spawn output and open it manually.

Scope

Make the multi-architect topology first-class throughout the Tower UX.

Required

1. /api/state returns ALL architects (array or keyed object), not just main. Each entry exposes name, terminalId, architectUrl. Backward compat: a state.architect scalar can stay as a main-or-first convenience pointer, or be removed if no consumer needs it (audit at plan time).
2. Dashboard renders one tab per architect. Tab label = architect name (main, architect-2, custom names). Tab body = that architect's terminal. Active-tab persistence per workspace.
3. VS Code extension Workspace sidebar view lists all architects. Each row clickable; opens that architect's terminal in a VS Code tab named Codev: <name> (architect).
4. afx status shows architect names alongside builders (e.g., a header line listing registered architects). The --architect <name> filter (deferred from Multi-architect support: per-architect identity + builder-to-architect message routing #755) lands here too: filters the builder list to those whose spawned_by_architect = <name>.

Out of scope (separate follow-ups)

• THREAD.md template + lifecycle (codev thread new/list/archive) — Multi-architect support: per-architect identity + builder-to-architect message routing #755 follow-up Scaling Crisis - AI Autonomy Decreases as Projects Grow #3
• Cross-thread visibility — Multi-architect support: per-architect identity + builder-to-architect message routing #755 follow-up Installation Process Failures - Multiple Steps Being Skipped #4
• Thread-aware consult — Multi-architect support: per-architect identity + builder-to-architect message routing #755 follow-up IDE Loop Misunderstanding - AI Doesn't Understand Phase Repetition #5

Constraints

• Single-architect workspaces see no behavior change. A workspace with just main should look identical in dashboard/VS Code/afx status. Multi-architect UI elements (extra tabs, list entries) only appear when N > 1.
• No new architect-identity model. Reuse the name field from spec Multi-architect support: per-architect identity + builder-to-architect message routing #755.
• Pure UI surface change. No Tower routing logic touched; the affinity-routing primitive is already in place from PR [Spec 755] Multi-architect support: builder→architect message routing #757.

Suggested protocol

SPIR — touches Tower routes (/api/state), dashboard components, VS Code extension Workspace view + builder-tree, and afx status formatter. Multi-surface, deserves design discussion at spec time.