The MCP plans in one call: `plan` opens several small issues and links them #355

The MCP now has a plan tool that opens up to 12 issues and all their links in one call, or opens nothing. I ran test/mcp.test.ts (13 pass). I did not run the forge's check command to the end: bun x tsc --noEmit fails here with "Cannot find type definition file for 'bun'", which looks like this sandbox rather than my change. The full bun test was noisy and I stopped it, so I haven't seen it finish.

• Input: { app, issues: [{ key, title, body?, blockedBy?: (key | number)[] }] }. blockedBy takes keys from the same call or numbers of issues already open in that app.
• Atomic: the issues and links are written in one transaction. Events (issue.opened, issue.blocked) are sent only after it commits, and the issues are attributed to the token's owner.
• Refusals: the whole plan is refused, naming the item, for a loop, an unknown key or number, a duplicate or malformed key, an empty or over-long title or body, or more than 12 items. Title and body limits are the issue API's own, MAX_TITLE and MAX_BODY.
• Access: an ro token is refused. Beyond that, the caller must be able to write the repo or be on its crew (the same rule as link), and mirrored repos are refused.
• Answer: a says sentence, opened: [{ key, number }], and ready, the numbers of the open issues nothing open stands in front of.
• Where it lives: the logic is in a new src/actions/plan.ts (parsePlan, openPlan), so the API can reuse it later. src/http/mcp.ts is only the tool wrapper. docs/MCP.md has a table row and a worked example.
• Tests: three issues where the third waits for the first two come back linked and ready is right. A cycle, an unknown key and 13 items each leave the issue count unchanged. An ro token gets forbidden. I also updated the tool-list expectation to include plan.
• Left out: there is no HTTP API endpoint for plans yet. Keys that look like numbers are not allowed, so a key can never be mistaken for an issue number. There are no new dependencies.

Closes #349