Self-deploy rollback, part 1: `bun src/main.ts --rollback <sha>` swaps back to a kept release, and refuses one whose schema is behind the live database #1846

bun src/main.ts --rollback <sha> now swaps to a kept release through startRelease, the same health-read swap a landing uses. If the health read fails, the old process keeps serving. bun x tsc --noEmit is clean. release-rollback, kernel, release-swap, release-checkout and check-list pass (46 pass, 1 skipped). test/db.test.ts doesn't exist, so I ran test/kernel.test.ts instead, which holds future schema refuses to run.

• Unknown or pruned sha: one line names the sha. A sha that isn't 40 hex characters is refused without being echoed or touching the filesystem.
• Older schema: a kept release with fewer migrations than the live database has applied is refused with <sha> predates schema N; rolling back would need a down-migration.
• Reading the schema: the live count comes from a read-only open of forge.db (schema_migration rows, or user_version on an old database). The release's count is migrations.length in its own src/core/schema.ts. A release with no readable schema is refused too.
• Newer schema: a release with a newer schema is allowed, because it migrates forward on boot. src/kernel/migrate.ts is untouched, so the future-schema refusal is as it was.
• Gate: test/release-rollback.test.ts is added to GATE in scripts/gate.ts in the same commit. It covers three cases:

- a known sha swaps and health names it; - an unknown or non-hex sha is refused; - an older-schema sha is refused.

Not done:

• Draining the old process: the rollback process can't signal it, so after a successful swap both processes serve on the port until the old one is stopped. The command prints rolled back: pid N and exits. The issue didn't ask for the drain, so I left it for part 2.
• Swap guards: beginSwap's SSH and kernel-migration guards are skipped, since they check the running forge's state and this command runs in a separate process.

To try it, run PORT=3000 bun src/main.ts --rollback <40-hex sha> against a data directory that has releases/<sha>/.

Closes #1823

I've added --rollback to the README and made the command say the old forge keeps running. It still doesn't drain that forge; I left that for part 2. tsc is clean and the four rollback tests pass. I didn't re-run the other suites, since only the README and one output string changed.

• README: bun src/main.ts --rollback <sha> now sits beside --preflight and says what it needs. It names the full 40-hex sha kept under $FORGE_DATA/releases/ and PORT. It gives both refusals and the exit codes: 0 once the release reads healthy as that sha, otherwise 1 with one line. It also says the swap budget is the 60s default, because the CLI doesn't read FORGE_SWAP_BUDGET_S. A paragraph after the swap description covers the schema rule and the part-2 gap.
• Old forge: I stated the gap rather than draining. A separate CLI process has no handle on the serving forge: it has no pid and no handover.drain, which only exist inside that process. A drain needs a pid record or a control route, and that is a design choice that belongs in part 2. Until then both processes share the port. The README says so, and on success the command now prints "the previous forge is still running on the port, stop it yourself".
• tcp_migrate_req: I disagree with "needs the same setup as the swap". The command doesn't check tcp_migrate_req, or whether the old process holds the SSH listener, so rollback itself works without them. The README says that stopping the old forge cleanly later needs that setting, and that the SSH port stays with the old process.

I added the missing tests, plus the optional PORT check. tsc is clean and all 10 tests in test/release-rollback.test.ts pass. I ran only that file this round, not the other suites.

• Newer schema allowed: with the live database at 3 and the kept release at 5, the rollback goes through. This would fail on known <= live or !==.
• Unreadable schema: a release with no src/core/schema.ts and one whose schema.ts throws on import are both refused with has no readable schema.
• liveSchema fallbacks: a database with only PRAGMA user_version = 4 reads as 4, and a rollback to a 2-migration release is refused as predates schema 4. A missing database reads as 0.
• PORT check: src/main.ts now rejects a PORT that isn't an integer from 1 to 65535. It exits 1 with one line.
• Command-line tests: two spawn tests run main.ts. A missing sha exits 1 with a single stderr line, and PORT=abc exits 1 with a single line naming PORT.