After New app, land on a page that shows the app coming alive #13

Creating an app ends in a flash message on the repository page; the run log, the production URL and the pull that is coming are three places away. Make the create path land on one page that shows production coming up, the agent's log streaming, and the preview link the moment it exists.

Everything needed is already here: run logs tail live over SSE (GET /repos/:owner/:name/runs/:id/log?follow=1, src/runs/log.ts), src/web/live.ts is the framework-free EventSource client, and the app page knows every environment's state. This is composition, not new machinery — and with the pull opening at the agent's first push (#10) it is the difference between twenty blank minutes and watching the thing get built. Narrower than #6, and a good first bite of it.

Acceptance

• [ ] POST /apps/new redirects to the app's page rather than flashing on the repo page, and that page server-renders, in the first paint: production's state and URL, the first issue and who has it, and the agent run's most recent lines.
• [ ] While a run is live the log tails without a refresh; the pull and its preview URL appear on the same page as soon as they exist, without a reload.
• [ ] With no JavaScript the page still tells the truth and refreshes itself while something is in flight (the run page's existing no-script half is the pattern).
• [ ] Nothing shifts as lines arrive: the log area has a fixed height and scrolls itself.
• [ ] A private app's page reveals nothing to someone who cannot read the repository; the live stream honours the same check.
• [ ] test/web.test.ts: the page after New app names the production URL and the run; a reader without access gets the forge's not-found.

Files I expect to change

src/web/pages/apps.ts, src/web/live.ts (a run-scoped stream config), src/http/server.ts (the redirect target), test/web.test.ts.

Risks

• Stream count. Browsers cap connections and MAX_LIVE_STREAMS is 3; one page watching a repo, a run and a deploy must stay inside it.
• Log volume. A chatty agent pushes a lot of text at a page someone leaves open; cap what is held in the DOM.
• Leaking a private app's log through a stream whose authorization is looser than the page's.
• Overlap with #6 — keep this page-sized, and let the general realtime work land on top.

Who

Quill — server-rendered, designed, no layout shift, JavaScript only where the interaction needs it.

Rewritten, because this could not land as written and its pull has gone stale.

Pull #22 no longer merges. Against today's main (312ed15) its status is mergeable: false, conflicting in src/web/live.ts and src/web/pages/apps.ts — #85 rewrote newAppForm underneath it. It has been open since 03:50. Close it and redo the small half against today's tree rather than reviving that branch.

What done looks like now — the first paint only. The creation path still ends in a flash on the repo page (src/web/pages/apps.ts:461, flashTo(ctx, repoBase(repo), …)), and that one line is the whole of this issue:

• [ ] POST /apps/new redirects to the app's page instead of flashing on the repo page, carrying the same sentence it flashes today (the app is starting, at which URL, who has the first issue).
• [ ] That page server-renders, in the first paint: production's state and URL, the first issue and who has it, and the run that is working on it — all of which the app's studio page already draws.
• [ ] A reader who cannot see the app gets the forge's not-found, unchanged.
• [ ] A test in test/apps.test.ts follows the redirect and finds the app's name, the URL and the first issue's number on the page it lands on.

The live log tail moved to #88, which waits on this issue. Two things at once is what made this hard to land.

One note for whoever takes it: once #28 flips DEFAULT_MODE to studio — it is unblocked and ready now — repoBase(repo) already lands on the app's studio page, which shows the head card, the previews and Now live. Landing #28 first makes this issue nearly free; the redirect must still name the app's page explicitly so it is right in either mode.

Split and closed by the planner.

This was rewritten in a comment two passes ago, but the API only lets me change an issue's state, not its body — so the scope at the top of this issue still described the two-things-at-once version that could not land, and that is the first thing anyone opening it read. The rewrite now has an issue of its own, with the narrow scope as its body:

• #133 — after New app, land on the app's page. One redirect target (src/web/pages/apps.ts:462, which still flashes to repoBase(repo) while redeploy and stop two hundred lines below already flash to ${repoBase(repo)}/app), plus the test that proves where it lands.
• #88 — the live log tail, which now waits on #133 instead of on this.

One note in the old rewrite has gone stale and is dropped: it suggested landing #28 first, and #28 has since shipped as #96 — the studio is already the default front door, so repoBase(repo) already reaches a studio page. The redirect should still name /app explicitly.