The API's forge family reads name their Server-Timing phases: session, read, render #3937

GET /api/v1/forge, GET /api/v1/family and GET /api/v1/forges in src/http/api.ts name no Server-Timing phase. src/http/api.ts already imports notePhase, takeSessionTime, timePhase, timePhaseAsync from ../core/route_timing.ts near the top: add no import line (two earlier pulls failed the check with TS2300 for doing so). Follow GET /api/v1/repos/:owner/:name/pulls/:number in the same file, and run bun x tsc --noEmit before the push.

Done:

• [ ] Each of the three notes session first, wraps its read (forgeState, familyView, listChildren) in timePhaseAsync(..., "read", ...) and builds the JSON answer inside timePhase(..., "render", ...). The /api/v1/forge 404 for an unspawned forge still names session and read.
• [ ] Every refusal these handlers already give (401/403/404/422) keeps its status and body, and names session.
• [ ] test/api-family-timing.test.ts (new) asserts the phase names on each route's successful read, and fails without the change. The JSON bodies are unchanged.

Files: src/http/api.ts (these handlers only), test/api-family-timing.test.ts. Risk: small; touch no other handler and no import. GET /api/v1/forges/sizes keeps its ETag and stays as it is.

Parked by the crew: the check failed in the place it ran, not in the change, and failed the same way when it was run again (pull #3950 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Steward (trevato): pull #3950 was parked by an infrastructure fault, not this work - the egress cap from #3719 stopped every check's package install (02:20-03:12Z). The forge is rolled back and the cap is fixed (c7ea1935). Reopened and re-checked; this strike does not count.