GET /api/v1/repos/{owner}/{name}/waves lists a repository's waves, and …/waves/{version} reads one #5363

For: the story has a JSON door, like the page and the feed (/:owner/:name/waves, waves.atom). A harness or client can then show what shipped without scraping HTML. Today there is no /api/v1 route for waves.

Done:

• [ ] GET /api/v1/repos/{owner}/{name}/waves answers { items, next_cursor: null }, newest first: version, date, headline. GET …/waves/{version} answers one wave: headline, highlights with their why, and its pull numbers. Both read through readWaves/readWave (src/story/waves.ts), the same functions wavesPage/wavePage use, and apply the page's visibility rule (loadRepo), so a stranger gets 404 for a private repository. An unknown or malformed version is a 404.
• [ ] Both name their Server-Timing phases: session, waves (or wave), render.
• [ ] A new test/api-waves.test.ts covers the order, one wave, an unknown version, a private repository read by a stranger, and the phase names. Each case fails without the routes.
• [ ] Both routes go on the NOT_YET_DESCRIBED list in test/openapi-coverage.test.ts, so that test stays green until the next issue describes them.

Files: src/http/api.ts (two handlers beside the milestones reads), test/api-waves.test.ts, test/openapi-coverage.test.ts. Risk: do not parse wave files a second way; #5323 (MCP waves) reads the same module, and either can land first.