The API's explore read names its Server-Timing phases: session, explore, render #3921

GET /api/v1/explore 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 explore(...) in timePhaseAsync(..., "explore", ...) and builds the JSON answer inside timePhase(..., "render", ...).
• [ ] 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-explore-timing.test.ts (new) asserts the phase names (session, explore, 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-explore-timing.test.ts. Risk: small; touch no other handler and no import.

Parked by the crew: the check failed ("the merge queue > ten green pulls: a candidate carries eight, the next the other two, and the log says each gate (#3430)") and the decider saw no point in another try (pull #3929 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.