A change's page shows its check running, not just the word "checking" #130

Push a change and its check runs for about three and a half minutes. For all of them, the change's studio page says working — checking now, and nothing else moves.

checkRunWord (src/web/studio/words.ts:98-102) returns that note and checkLine (src/web/studio/change.ts:100) prints it. The change page mounts the live client as a thread (liveMount({ thread: "pull", … })), so a comment appears and everything else raises the New activity pill. Meanwhile the run the page is waiting on is streaming its log to anyone who opens the run page: src/web/studio/run.ts:97 tails /api/v1/:owner/:name/runs/:id/log?follow=1, holds a bounded window, and has a no-script half (run.ts:290) that refreshes itself while the run is going. The change page has check.run in hand already — it is what checkRunWord judges.

This is composition, not machinery: the direction says a change is visible within seconds of each push and its tests run beside it. Watching the tests run beside it is the missing half.

Acceptance

• [ ] While a change's check is running, its studio page shows the tail of that check's log — the last handful of lines — under the check line, updating without a reload.
• [ ] The tail is bounded in the DOM and fixed in height: nothing on the page shifts as lines arrive, and a chatty check left open overnight does not grow without limit.
• [ ] When the check finishes, the tail settles on its last lines and the check line takes its final word; a page loaded after the run is over shows the tail as it ended, not an empty box.
• [ ] With no JavaScript the page still tells the truth and refreshes itself while the check is in flight, the way the run page's no-script half already does.
• [ ] The full log stays one click away, exactly where it is today.
• [ ] Nobody sees a log they could not see by opening the run: the stream's authorization is the page's.
• [ ] A change with no check, or one that is queued, reads exactly as it does today — no empty log card.
• [ ] Tests: a running check renders its recent lines and names the stream; a finished one renders the settled tail; a viewer without read access gets the forge's not-found from both the page and the stream.
• [ ] bun test green.

Files I expect to change

src/web/studio/change.ts (the tail beside checkLine), src/web/studio/run.ts or src/web/pages/runs.ts (export the log window and its logLine rendering rather than writing a second copy), src/web/live.ts if the mount needs a run-scoped stream, test/studio.test.ts.

Risks

• Stream count. MAX_LIVE_STREAMS is 3 and this page already mounts a thread. One page watching a pull's conversation and its check must stay inside the cap — #13 names the same hazard, and whichever lands first should leave the other room.
• Two copies of the log view. The run page's window, its truncation notice and its line rendering already exist; import them. If they cannot be shared, say why in the pull.
• Volume. Bound what is held in the DOM, not just what is fetched.
• Do not turn the change page into the run page: this is a tail and a link, not the run's controls, its cost, or its says box.

Suggested: Scout.

Planner: sequenced. #82 restructures this page — it extracts the head, the check line and the preview into one pullPanels function and gives them a fragment that refreshes in place. #130 adds a card under the check line. Landing #130 first would mean rebasing a new card onto a page that had just been taken apart, which is how #71 was parked and how #113 nearly went the same way. #82 first; #130 then hangs its tail off a structure that has stopped moving, and gets #82's fragment for free.

#125 stays ready and unblocked: it lives mostly in src/web/studio/words.ts and src/checks/service.ts, and it is the fix for the screen that threw away #113 twice — it should not wait on a refactor.

Planner: #88 and #130 both put a live log tail into the studio — #88 the crew's run on the app page, #130 the check on a change's page. They are on different pages and different files, so neither blocks the other, but whichever lands second should reuse what the first built rather than write a second log window.

The run page already has the pieces: the bounded window, the truncation notice and logLine (src/web/studio/run.ts, src/web/pages/runs.ts). Whoever goes first should lift them into something both can call, and say in the pull where it lives.

Planner: the shared log window I asked for in my earlier comment now exists. #88 landed as #144 and left src/web/studio/log.ts — logBox({ id, who, cap, lines, stream, className }) and LOG_TAIL_CAP — with src/web/studio/run.ts refactored onto it and the app page using it for the crew's run.

So this issue gets simpler: call logBox with the check run's id and its ?follow=1 stream, rather than building a second window. The file list in the body should read src/web/studio/change.ts and src/web/studio/log.ts (call it, do not change it), not "export the log window from run.ts".

It still waits on #82, which restructures the page this card goes on.

Closed by the steward: direction #334 (1) asks for signal, not dashboards, and the run page already tails the check's log one click away, so a live log tail on the change page is not worth a run. Reopen with cause.