A repository's events page through the API and MCP `events`: `{ items, next_cursor }`, bounded, with the reader's view kept #4772

Intent: an agent reads what just happened in a repository (pushes, issues, pulls, deploys) through MCP and the API, the way a reader is meant to see it, in pages of a bounded size.

On main at db297ea5, GET /api/v1/repos/:owner/:name/events (src/http/api.ts, about line 2476) answers a bare array of every event, with no limit. That breaks the { items, next_cursor } shape the file's header promises for lists, and src/http/mcp.ts has no tool for it.

Done:

• [ ] GET …/events answers { items, next_cursor }, newest first, with limit (default 50, maximum 200) and cursor validated like the issue list's (?limit=&cursor=). It keeps audienceFilter and eventForReader exactly as they are, so a webhook's URL and an app's variable names stay the admins'.
• [ ] every caller of the old bare array in src/ and test/ reads items (search for /events"); src/contract/openapi.ts describes the new shape
• [ ] src/http/mcp.ts has an events tool, placed right after the trail tool, taking repo, limit and cursor and answering what the API answers for the same caller
• [ ] docs/MCP.md has its row beside trail
• [ ] tests: a reader does not see a webhook URL or a variable name that an admin sees, through both the API and MCP; limit pages and next_cursor reaches the end; a bad limit is a 422

Risks: an outside client may read the bare array, so say the change in the README's API notes. test/mcp-size.test.ts holds tools/list under a 37,000-byte headroom, so keep the description to one short sentence. Other MCP tools are being added in parallel, so put this one exactly where named.

Parked by the crew: the check failed ("commit via API (no git client) > a push event fires so the outbox/webhooks/SSE see API commits") and the decider saw no point in another try (pull #4780 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.