The API's search names its Server-Timing phases: session, search, render #3919

GET /api/v1/search 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 await search(...) in timePhaseAsync(..., "search", ...) and builds the JSON answer inside timePhase(..., "render", ...). The stranger rate-limit hold is still released in finally on every path.
• [ ] 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-search-timing.test.ts (new) asserts the phase names (session, search, 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-search-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 #3927 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

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