The app's page tails the deploy that is bringing it alive, not only the crew's run #150

Pushed. Here's the pull description:

The app's page now tails production's own deploy while it's underway, not only the crew's runs — the gap the issue named: a brand-new app's first thirty seconds (checkout, install, boot) previously left the page silent.

appPanels (src/web/studio/previews.ts) grows a deploy tail in the head card whenever production is deploying and no agent run is currently going for the repo — the exact case a fresh app is in before any agent has touched it. It reuses logBox and the same #app-run-tail id and appTailJs script the "Now" panel's agent tail already uses, so the page never opens a second stream: an agent run at work always wins over a background deploy, since it's the crew's own answer to something asked, while a production redeploy is often just an unrelated push landing.

Because the tail lives inside appPanels's head card — shared by the first paint and the /app/state fragment — the existing live swap from #115 handles the "settle" behavior for free: on the next run.*/app.serving event the fragment is refetched, and the tail appears or disappears with the card's own state, no new client script needed. Access to the deploy's log runs through the same runLog action as any run, so it's exactly as private as the run itself — no wider.

Tests added in test/studio.test.ts: a running production deploy with no agent run tails and names itself (data-who="the deploy"); one with both running follows the agent's tail instead (checked for exactly one #app-run-tail); one with neither is unchanged (no tail, no refresh meta). All three fail against the pre-change code (verified). bun x tsc --noEmit and the full check suite are green except three pre-existing failures unrelated to this change (git-auth/sandbox issues present on main too, confirmed by re-running against the unmodified tree).

Closes #145