Implement internal/rollback and the service control it needs

Rollback was the one phase gating everything else: `run` without --dry-run
refused because this tool could not undo a cutover it had committed to.
That reason is now gone, and the refusal has narrowed to the fact that
there is no real cutover to undo yet.

internal/rollback implements ARCHITECTURE.md 4.8 as eight checkpointed
steps under PhaseRollback: verify-backup, stop-service,
preserve-failed-state, restore-data, restore-binary,
restore-service-config, start-service, verify-rollback.

Three things depart from what 4.8 specified, each for a reason:

- The backup is re-verified against its manifest *before* the service is
  stopped, which the design didn't call out. Finding a corrupt backup is
  survivable while the failed instance is still up, and unsurvivable once
  its data directory has been moved aside.
- BuildPlan is separate from Run, so every reason to refuse (closed
  rollback window, FoundationDB, no recorded backup, unknown deployment
  kind, missing database credentials) is found before anything is touched.
  The CLI prints that resolved plan and acts only with --yes.
- The restore is re-verified against the same manifest after writing. A
  restore that put back truncated bytes and reported success would be
  worse than one that failed outright.

Nothing from the failed attempt is deleted: the half-migrated data
directory and the displaced binary are moved to .failed-<run-id> names, so
a retry after the underlying issue is fixed still has both the evidence and
the artifacts. Afterwards a reduced validation suite runs against the
*restored* instance (version, reachability, directory counts) rather than
assuming the restore worked.

internal/service is a new package holding the systemd/Docker control this
needs. It's separate rather than living inside internal/rollback because
cutover will need the identical operations, and because the commands that
can take mail delivery down belong in one auditable place - the same
reasoning that makes stalwartapi the only thing speaking JMAP.
preflight.DeploymentKind is now a type alias for service.Kind so detection
and control can't drift apart. Its Active() reads `systemctl is-active`'s
output rather than its exit status: systemctl exits non-zero for every
non-active state, so exit-status logic would make "inactive" - the answer a
rollback most needs - look like a failure to read the state at all.

Also fixes a pre-existing bug in `status`: Go's flag package stops parsing
at the first positional argument, so `status <run-id> --state-dir X` looked
the run up in the default directory and reported it missing. `rollback`
would have inherited the same footgun on a command whose flags decide what
gets overwritten.

Still open: `confirm` cannot set RollbackWindowClosed. Rollback honours the
flag and refuses when it's set, but closing the window is the point of no
return for the backups this restores from, so it should land with the
retention policy 6 describes rather than before it.

Verified end to end against a fake systemd deployment: half-migrated data
restored to its original contents, failed state preserved, old binary
reinstalled and reporting 0.15.5, unit restarted, and a re-run of the
completed rollback inert.

cmd/stalwart-migrate/run.go

@@ -17,12 +17,10 @@ import (
 )
 
 // runRun implements `stalwart-migrate run`. Only --dry-run is available
-// today: a real cutover needs internal/rollback (so a failed migration can
-// actually be undone) and real systemd/Docker service control, neither of
-// which exist yet - see ARCHITECTURE.md §8. Committing to a real migration
-// without a working rollback would violate the one thing this whole tool
-// exists to guarantee, so `run` without --dry-run refuses rather than doing
-// it partway.
+// today: the cutover phase itself (§4.5) isn't built. internal/rollback and
+// internal/service now exist, so the missing piece is no longer "this can't
+// be undone" but "there's nothing here to undo" - see ARCHITECTURE.md §8.
+// `run` without --dry-run refuses rather than doing a migration partway.
 //
 // --dry-run runs preflight and a real backup (see the caveat printed below
 // about why backup still touches the live data directory), then - if the
@@ -70,8 +68,9 @@ func runRun(args []string) (err error) {
 
 	if !*dryRun {
 		return fmt.Errorf(
-			"real (non-dry-run) migrations aren't available yet: internal/rollback and real systemd/Docker service control " +
-				"aren't implemented, so this tool can't yet guarantee it can undo a failed cutover. Run with --dry-run to " +
+			"real (non-dry-run) migrations aren't available yet: the cutover phase - installing the new binary, rewriting the " +
+				"service definition, and starting the migrated instance for real (ARCHITECTURE.md §4.5) - isn't implemented. " +
+				"Rollback is, so a future cutover will be undoable; there just isn't one to undo yet. Run with --dry-run to " +
 				"validate the migration mechanics against a disposable sandbox copy of your data - nothing in production is touched",
 		)
 	}
@@ -136,9 +135,9 @@ func runRun(args []string) (err error) {
 	fmt.Printf("\nplan: %s\n", p.Reason)
 
 	fmt.Println("\n--- backup ---")
-	fmt.Println("(dry-run does not stop the live Stalwart service itself - no service control is implemented yet. " +
-		"For a guaranteed-consistent snapshot, stop stalwart before running this; otherwise the filesystem copy may " +
-		"reflect a live, in-use store. This is unrelated to whether production gets touched - it never does.)")
+	fmt.Println("(dry-run does not stop the live Stalwart service itself - internal/service can now do that, but dry-run " +
+		"isn't wired to offer it. For a guaranteed-consistent snapshot, stop stalwart before running this; otherwise the " +
+		"filesystem copy may reflect a live, in-use store. This is unrelated to whether production gets touched - it never does.)")
 
 	backupDir := filepath.Join(runWorkDir, "backup")
 	scriptDest := filepath.Join(runWorkDir, "migrate_v016.py")