The new forge page's Server-Timing names its phases: session, each read, render #3471

GET /forges/new now answers with a Server-Timing header naming session, room, repos, crew and render. The tests I ran pass: the new timing test and the existing new-forge tests (14 in all). The type check did not run: bun install failed in the sandbox (bun could not write its tempdir, so node_modules is empty), so tsc isn't installed here. I pushed anyway; the forge's check will run it.

The new test, test/new-forge-timing.test.ts, requests the page signed in and asserts each phase appears exactly once with a numeric duration. It asserts names only, never a wall-clock time.

• Phases: session is the session time, and room is the capacity check. repos is the visible-repositories read, and crew is the agent list. render covers only building the body, not the reads. Each phase uses notePhase/timePhase the way milestones.ts does.
• Refactor: I moved the reads out of formView into a small readsFor in src/web/pages/new-forge.ts, so formView takes them as an argument. Their order is unchanged: room, then repos, then crew. A stranger gets no crew phase. A forge with no room gets only room. The body, status codes and caching are unchanged.
• Left out: session and render are noted on the GET only. The POST re-render of the form (a plan, or a refusal) also gets room/repos/crew phases, because it shares readsFor. I left the POST handler's own timing alone, and no other page is touched.
• Check: the sandbox denied outbound connections to *--forge.test hosts during the existing tests; they still passed.

I did not try it against a running app. To see it, sign in and request /forges/new, then read the server-timing response header.

Closes #3460

GET /forges/new now answers with a Server-Timing header naming session, room, repos, crew and render. The tests I ran pass: the new timing test and the existing new-forge tests (14 in all). The type check did not run: bun install failed in the sandbox (bun could not write its tempdir, so node_modules is empty), so tsc isn't installed here. I pushed anyway; the forge's check will run it.

The new test, test/new-forge-timing.test.ts, requests the page signed in and asserts each phase appears exactly once with a numeric duration. It asserts names only, never a wall-clock time.

• Phases: session is the session time, and room is the capacity check. repos is the visible-repositories read, and crew is the agent list. render covers only building the body, not the reads. Each phase uses notePhase/timePhase the way milestones.ts does.
• Refactor: I moved the reads out of formView into a small readsFor in src/web/pages/new-forge.ts, so formView takes them as an argument. Their order is unchanged: room, then repos, then crew. A stranger gets no crew phase. A forge with no room gets only room. The body, status codes and caching are unchanged.
• Left out: session and render are noted on the GET only. The POST re-render of the form (a plan, or a refusal) also gets room/repos/crew phases, because it shares readsFor. I left the POST handler's own timing alone, and no other page is touched.
• Check: the sandbox denied outbound connections to *--forge.test hosts during the existing tests; they still passed.

I did not try it against a running app. To see it, sign in and request /forges/new, then read the server-timing response header.