Specs: a migration tool, with rollback as a path rather than an appendix

INBUXA's cutover is the first run of something other operators will want:
an existing Stalwart server becoming an INBUXA one with nothing re-entered
and nothing re-issued. Accounts, passwords, app passwords, OAuth sessions,
aliases, tenants, DNS records and provider settings, certificates and ACME
state, Sieve scripts, the queue and the mail all live in the store, so a
migration that copies the store carries them.

Offered beside the fresh-install workflow, which has different questions to
ask, so §6.1 now names both.

It rolls back, which is where it parts company with stalwart-migrator:
that one upgrades in place and says outright it cannot undo a migration.
This one never writes to what it migrates from, so going back is stopping
one service and starting another. Rollback is automatic when verification
fails, available on demand while the old install stands, honest about the
mail that stays behind, and never points the old server at the store the
fork has written.

Every phase is timed, and the number to advertise is the downtime, phases
2 to 7, not the total that preflight and the copy dominate. The report
writes both as JSON so a release note quotes something measured.

docs/spec/cutover.md

@@ -2,7 +2,9 @@
 
 Status: draft, 2026-09-19. Nothing here has been rehearsed yet.
 
-SPEC.md §7 step 4. Steps 1 to 3 are met: the fork builds and its suites pass
+SPEC.md §7 step 4. This run is also the first run of the migration tool
+INBUXA will ship (`migration.md`): what is done by hand here is what that
+tool automates, including its rollback. Steps 1 to 3 are met: the fork builds and its suites pass
 (`container-tests.md`), and all eight compat tests pass against a copy of
 INBUXA's store (`compat-tests.md`). What is left is running it as the mail
 server.