POST /api/v1/admin/releases/:sha/rollback plans, then rolls the forge back to a kept release, with the releases page's rules #7217

For: a forge admin's script or harness can roll back a bad release over the API. It stays deliberate: a plan first, then an explicit apply.

Today only /releases (src/web/pages/releases.ts:93-100) and the terminal (src/tui/screens/releases.ts:121) call rollBackTo. /releases.json only reads.

Done:

• [ ] A new src/http/api/rollback.ts, registered with one line beside reportRoutes. POST /api/v1/admin/releases/:sha/rollback with { "dryRun": true } (the default) answers from which release to which, and whether canRollBackTo allows it, and changes nothing. With dryRun: false it calls rollBackTo and answers the receipt.
• [ ] The admin gate (src/http/admin_gate.ts) already refuses a non-admin with not_admin. In addition, a token without admin scope is forbidden, an unknown or not-kept sha is not_found, and a release the live schema forbids is 409 with the page's words.
• [ ] The route is in the OpenAPI document (a new file under src/contract/openapi/routes/), and test/openapi.test.ts passes.
• [ ] A new test/api-rollback.test.ts covers: the plan answers and nothing moves, a member and an rw token are refused, and an unknown sha is not_found.

Files: src/http/api/rollback.ts, one OpenAPI route file, one test. Risk: medium. This touches self-deploy. Reuse rollBackTo and canRollBackTo from the release gate unchanged.