The API's board panel read names its Server-Timing phases: session, board, query, render #3920

GET /api/v1/boards/:slug/panels/:id 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 showBoard in timePhaseAsync(..., "board", ...), panelData in timePhase(..., "query", ...), and the JSON or CSV answer in timePhase(..., "render", ...). cache-control: private, no-store is kept on both formats.
• [ ] 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-panel-timing.test.ts (new) asserts the phase names (session, board, query, 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-panel-timing.test.ts. Risk: small; touch no other handler and no import. The test needs a site admin (boardsAdmin).

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

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