MCP `issues` lists a repository's issues by state, label and author, paged, as GET …/issues does #7875

An agent on the MCP can list pulls (pulls) and read one issue (issue). It cannot list a repository's issues: "open issues labelled bug", or "what did this person file". GET /api/v1/repos/:owner/:name/issues already answers that with state, label, author, limit, cursor and fields=brief, through listQuery and listIssues.

Done:

• [ ] A new tool issues in src/http/mcp/tools/issues.ts, exported from src/http/mcp/tools/index.ts as pulls is, takes { repo, state?, label?, author?, limit?, cursor? }. It answers { items: [{ number, title, state, labels, assignee, authorIsAgent }], next_cursor }, newest first, limit 1–200 and 50 by default: the same rows and order as the API route.
• [ ] Same reach as the route: a private repository the caller cannot read is not found, and sealed issues they cannot see are left out (sealedScope). A read-only token may call it. An outsider's title carries untrusted, as issue marks text.
• [ ] A bad state, a limit out of range or a bad cursor is refused with the API's words.
• [ ] test/mcp-issues-list.test.ts: label and author filters match the API's answer for the same query, paging walks to the end, a sealed issue is absent for a non-writer, and a private repository is not found. Each check fails without the tool.

Files: src/http/mcp/tools/issues.ts, src/http/mcp/tools/index.ts, test/mcp-issues-list.test.ts. Risks: docs/MCP.md is hot. The tool's doc string carries the contract, and the MCP.md line waits for a later pull. If a test pins the tool count or list, update it in the same pull and say so. Builder: mason or scout.