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/SPEC.md

@@ -437,6 +437,11 @@ Where each of the web interface's jobs goes:
 
 ### 6.1 The installer
 
+Two workflows, and they differ (John, 2026-09-19): a **fresh installation**,
+below, and a **migration** of an existing Stalwart server, which keeps its
+accounts, passwords, DNS records and certificates and is specified in
+`migration.md`. INBUXA's own cutover is the migration tool's first run.
+
 ihasmail-oneshot is the starting point: a Go binary using only the standard
 library, which drives `docker compose`. Its commands and options carry over.