The app's studio page shows a new deployment arriving without a reload #35

When a push lands while you are looking at an app, the page should show the new deployment come up by itself, instead of offering a refresh pill.

The studio app page mounts the live stream (liveMount in src/web/pages/studio.ts), but everything it can do with an event is reveal "New activity - refresh" (src/web/live.ts). So the moment the direction is about — a change serving in its preview seconds after a push — is a moment the page you are on does not show. Deploys here are fast (production deploys of trevato/cs finish in 3-5 s), which makes the manual refresh the slowest part of watching a change land.

Done looks like

• [ ] On a deploy run event for the app being viewed, the head card refreshes itself in place: state dot, badge, commit, and the served phrase (servedPhrase, src/web/ui.ts) — including the "N s after the deploy started" wording that #26 landed.
• [ ] The previews list from #25 refreshes with it: a preview that comes up turns live, one that fails says so, and the links stay correct.
• [ ] One fragment endpoint serves that markup for both the first paint and the refresh — the page and the update render from the same function, never two copies of the same HTML.
• [ ] No layout shift when a row changes state, and no new dependency; the client stays a handful of lines in src/web/live.ts reading data attributes, never interpolated script text (the CSP forbids it).
• [ ] The fragment is authorized exactly as the page is: a viewer who cannot see the app gets the same answer as on the page, and the response carries the security floor's headers.
• [ ] With JavaScript off, the page is what it is today; the refresh pill still covers everything that is not a deploy.
• [ ] Tests in test/studio.test.ts and test/live-pages.test.ts: the fragment renders the head card for a viewer who may see it, refuses one who may not, and shows a preview flipping from deploying to live between two calls.
• [ ] docs/STUDIO.md gains a line: the app page keeps itself current about deployments.

Files I expect to change

src/web/pages/studio.ts, src/web/live.ts, src/http/router.ts (one route), src/web/ui.ts if the shared fragment belongs there, test/studio.test.ts, test/live-pages.test.ts, docs/STUDIO.md.

Risks

• A per-event fetch storm during a burst of pushes: coalesce to at most one fetch in flight, and let the pill handle everything else.
• Duplicating the card's markup in a second place is the failure mode here; one function or nothing.
• Depends on the previews card (#25) and on a preview that can actually boot (the preview-data issue below it).

Suggested: Scout — one page, little JavaScript, instant feedback, with tests.