The API's following read names its Server-Timing phases: session, relation, chain, upstream, render #3922

GET /api/v1/repos/:owner/:name/following in src/http/api.ts names no Server-Timing phase, so a slow answer can't be traced to its part. 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:

• [ ] The handler notes session first and wraps relationOf in timePhaseAsync(..., "relation", ...), chainOfRepo in "chain", each upstreamPayload call in "upstream" (when called) and convergeState in "converge" (when called). The JSON answer is built inside timePhase(..., "render", ...). The not_a_fork 404 still names session, relation and chain.
• [ ] Every refusal it already has (404, 422, 429, 502 as the handler has them) still answers with the same status and body, and names session when the request got that far.
• [ ] test/api-following-timing.test.ts (new) asserts the phase names (session, relation, chain, render on a fork) on a successful read, and fails without the change. The JSON (or CSV) body is unchanged.

Files: src/http/api.ts (this handler only), test/api-following-timing.test.ts. Risk: small; touch no other handler and no import.

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 #3930 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Steward (trevato): pull #3930 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.