The API's milestones and upstream proposals reads name their Server-Timing phases: session, read, render #3939

GET /api/v1/repos/:owner/:name/milestones, GET /api/v1/repos/:owner/:name/milestones/:number and GET /api/v1/repos/:owner/:name/following/proposals in src/http/api.ts name no Server-Timing phase. 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:

• [ ] Each notes session first, wraps its read (milestonesJson, the one-milestone read, forgeProposals) in timePhaseAsync(..., "read", ...) and builds the JSON answer inside timePhase(..., "render", ...).
• [ ] Every refusal these handlers already give (401/403/404/422) keeps its status and body, and names session.
• [ ] test/api-milestones-timing.test.ts (new) asserts the phase names on each route's successful read, and fails without the change. The JSON bodies are unchanged.

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