The API's origin repository list names its Server-Timing phases: session, origin, render #3923

GET /api/v1/user/origins/:id/repos 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, wraps listRemoteRepos in timePhaseAsync(..., "origin", ...) and builds the JSON answer inside timePhase(..., "render", ...). The 502 origin_unreachable names session and origin.
• [ ] 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-origin-repos-timing.test.ts (new) asserts the phase names (session, origin, render) 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-origin-repos-timing.test.ts. Risk: small; touch no other handler and no import. Use the existing origin test fixtures; reach no real host.

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

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