GET /api/v1/explore answers `{ items, next_cursor }`, and MCP `explore` takes the cursor #6413

Seen on production: /api/v1/explore answers { query, items } with no cursor, unlike the lists that moved to { items, next_cursor }, so an agent cannot read past the first page.

Done when:

• [ ] The route keeps query and items and adds next_cursor (null on the last page); ?cursor= reads the next page at the page size it already uses, and a malformed cursor is a 400 with the forge's usual refusal shape.
• [ ] MCP explore accepts cursor and answers next_cursor, through the same function.
• [ ] Tests: with more public repositories than one page, following next_cursor reaches every one exactly once in rank order; a bad cursor is refused; test/api-explore-timing.test.ts still passes.
• [ ] The OpenAPI document describes the cursor.

Files: the explore API route and its core read, src/http/mcp/tools/explore.ts, the contract, test/explore.test.ts. Risk: the ranking must be stable for the cursor; key it on (score, id), not score alone.

Deferred behind the Later gate (#595). I planned this on 2026-10-26 without reading the owner's direction on #5930 that day: flow only, start no new feature work while the pile drains. This is feature work, so it waits until a person opens the gate.