Show a chat's terminals as a strip above the composer

[Edward-Upton]

Problem

A chat can have several terminals: a dev server, a test watcher, a one-off shell. Today the only sign of them in the chat view is the terminal drawer, and you have to open it to see anything. The sidebar row shows a pulse when a terminal process is running, but not which terminal, how many, or what it runs.

So I lose track of what each chat has running. I open the drawer and click through tabs to find the dev server. When I settle a chat, I forget it still has a process running (related: #10089).

Proposal

Add a compact terminal strip to the composer's top dock, in the same row as the tasks tab and stash badge. Show it only when the chat has at least one terminal.

 ┌───────────────────────────────────────────────┐
 │ ● pnpm dev   ● vitest --watch   ○ term-3      │  ← terminal chips
 ├───────────────────────────────────────────────┤
 │ Ask anything…                                 │
 │                                    ◔ 42%  ⏎  │
 └───────────────────────────────────────────────┘

Each chip shows:

Element	Source
Label	The running child command (childCommandLabel / TerminalSummary.label), falling back to the terminal id
Running dot	hasRunningSubprocess. Same teal colour and synced pulse as the sidebar indicator
Exited state	status / exitCode. Muted chip, red if it exited non-zero

Interactions:

• Click a chip to open the terminal drawer on that terminal.
• Hover for the cwd and full command.
• With more than about 3 terminals, show the first few and a +N chip.
• Hide the strip when the drawer is already open, since the drawer tabs show the same information.

Why it fits

• No server or contract changes. subscribeTerminalMetadata already streams TerminalSummary per chat. ChatView already builds activeThreadKnownSessions and activeTerminalLabelsById for the open chat.
• No new websocket traffic. It reads state the client already holds.
• Design consistency. It reuses the composer top dock (ComposerBanner.Dock) and the existing terminal status colours and pulse. It adds no new animations.

Scope and open questions

• Agent shells. Agent-run shells (Claude Bash, Codex commands) are out of scope for v1. They are a separate system, and the background-work banner already covers them. They could be a follow-up.
• Mobile. Mobile could show the same strip above its composer later. Is that needed in the first PR?
• Placement. Is the top dock the right place, or would you prefer a single "N terminals" chip next to the context-window meter that expands on click?

I'm happy to implement this if the direction and scope are approved.