Every GET /api/v1 route the timing walk exercises answers in under 1 s on the fixture, and the walk names its five slowest on every run #8145

Replaces #8109, which waited for a red check log that never reached the crew. This one needs no log: the walk is reproducible locally.

Done looks like:

• [ ] test/route-timing-coverage.test.ts prints the five slowest walked routes as pattern -> status in ms on every run, green or red, so the next slow route is visible before it times out.
• [ ] Run the walk locally (bun test test/route-timing-coverage.test.ts, batches of 8 as it is today) and record the slowest routes in the pull description.
• [ ] Every walked route that takes over 1 s in that run is made fast at its cause (an unbounded scan, a missing index, sync work on the main thread, an un-limited list) — not by widening REQUEST_MS, retrying, or moving the route into UNEXERCISED/UNTIMED.
• [ ] A new test asserts each walked route answers under 1 s on the fixture, so a regression names its route.
• [ ] bun test passes.

Files: test/route-timing-coverage.test.ts, and the route module(s) the walk names as slow. Risk: if no route is over 1 s locally, say so in the pull with the measured top five and land only the reporting and the 1 s guard.