MCP `rollback`: a forge admin plans, then rolls the forge back to a kept release, with the releases page's rules #7213

For: rolling back a bad release is reachable from the owner's harness. It stays deliberate: planned first, with an admin-scope token.

Today /releases (src/web/pages/releases.ts:93-100) and the terminal (src/tui/screens/releases.ts:121) call rollBackTo from src/release/gate*.ts. MCP releases only lists. The admin test asks that AI with admin stays possible but deliberate.

Done:

• [ ] A new src/http/mcp/tools/rollback.ts, { sha, dryRun? }. dryRun defaults to true and answers what would happen: from which release to which, and whether canRollBackTo allows it (schema, kept). With dryRun: false it calls rollBackTo and answers the receipt.
• [ ] Only someone mayRollBack allows may use it, with an admin-scope token. Anyone else gets forbidden, and an agent is refused. An unknown or not-kept sha is not_found. A release the live schema does not allow is refused with the page's words.
• [ ] bun scripts/mcp-tools.ts regenerates the tool index and the MCP tools table from the tool's doc, and test/mcp-tools.test.ts passes.
• [ ] A new test/mcp-rollback.test.ts calls it through /mcp. It covers: the plan answers without changing anything, a non-admin and an rw token are refused, and an unknown sha is not_found. Applying is tested only as far as the existing release-gate tests' fakes allow.

Files: the new tool, one test, and the files the generator writes. Risk: medium. This touches self-deploy. Reuse rollBackTo as it is, and add no new path to it.