GET /api/v1/keeper answers the release keeper's releases, holds and what blocks the next cut, as MCP `release_keeper` does #8024

Intent: whether the next release can go out is readable over HTTP by any harness; today only MCP release_keeper (src/http/mcp/tools/release_keeper.ts), the terminal's keeper screen and the /releases card answer it.

Done looks like:

• [ ] The tool's answer ({ blocked, releases, holds } from blocking(standingHolds(db)), listKeeperReleases, listHolds) comes from one exported function, keeperAnswer(db) in src/keeper/record.ts; the MCP tool calls it and answers exactly as today.
• [ ] A new src/http/api/keeper.ts registers GET /api/v1/keeper: whoever mayRead (src/release/gate.ts) admits gets 200 with that answer; anyone else gets 403 forbidden with "the release history is for the forge's administrators and its repository's readers".
• [ ] src/http/api.ts: the import goes directly after the hookRoutes import and the call directly after hookRoutes(router); (other issues register elsewhere).
• [ ] src/contract/openapi/routes/getApiV1Keeper.ts describes it (the 403 refusal), exported from src/contract/openapi/routes/index.ts in its alphabetical place.
• [ ] A new test/api-keeper.test.ts proves: an admin gets the same object MCP release_keeper returns, with a seeded hold showing in blocked; a stranger gets 403; the route is in the OpenAPI document. It fails without the change.
• [ ] bun test test/api-keeper.test.ts test/mcp-size.test.ts passes.

Files: src/keeper/record.ts, src/http/mcp/tools/release_keeper.ts, src/http/api/keeper.ts, src/http/api.ts, src/contract/openapi/routes/getApiV1Keeper.ts, src/contract/openapi/routes/index.ts, test/api-keeper.test.ts Risks: read-only; holding and lifting stay where they are. Brief: a builder who knows the API.