Show what is happening at least every 10 seconds during long steps, above all the first build #68

Requirement. While a specialist is at work, the person should see something new about what is happening at least every 10 seconds. This matters most during the initial build of an app, when the coder runs for a long time before anything shows in the app pane.

What the page shows today, and how often it can change.

The polls are frequent enough; the problem is that the content goes quiet. The phrase is a fixed reading of the latest tool call, so during a single long call nothing on the page changes except the clock:

• workspace setup (bun install) can run up to 115 s (SETUP_TIMEOUT_MS), with no words at all during it,
• a sandbox command such as check-app can run up to 120 s (commandTimeoutMs) and check-app itself up to 100 s before printing,
• a dev-app install in the live-app host can run up to 290 s,
• a long model turn between tool calls shows "thinking" for as long as it takes.

Seen on 2026-11-02: the first coder said nothing for its whole setup, then the person saw "Running a quick check 11m" (#63) and later "Shaping routine view 42m", with the app pane reading only "setting up your app" plus an elapsed clock for over 40 minutes, while the coder was in fact writing a file every 20 to 30 seconds.

What would meet it.

1. Use the progress the hub already has. RunProgress carries filesWritten, the last 8 files, turns and lastActivityAt. During the first build the app pane could say "12 files written, last: routines.tsx, 20 s ago" and update on each poll, instead of a bare elapsed clock.
2. Stream long commands. The sandbox runner collects stdout only at exit. Let it report the last line of output while a command runs (setup, check-app, installs) so the live line can read "installing packages: 143 of 396" or "check-app: opening page 7 of 18". check-app and bun install already print progress lines.
3. Stage phrases for the first build. The coder's build plan has named phases (the plan's seven steps here). The live line and the app pane could name the current phase and step, drawn from the coder's own reports, rather than the last file name.
4. Fill silence. When nothing new has arrived for 10 s, the live line should still move: show time since the last event and what is being waited on ("still installing packages, 45 s"), so a stall is visibly a stall and not a frozen page.
5. Finish faster to first paint. Start serving the starter app as soon as setup completes, so the pane shows something within the first minute, then live-reload as pages land.

Related: #62 (decision cards appear only on reload), #63 (a parked run shows its last activity), #67 (stale specialist runs).