Wire the container path up, behind a flag that says what it is

Everything the container migration needs has landed a piece at a time and
nothing called any of it. `run` now does: stage pulls and verifies an image
instead of downloading a binary, the recovery cycle launches a throwaway
container against the live container's own mounts, and cutover recreates it.
Preflight's blanket refusal of docker goes with it -- what still refuses is
specific to a container rather than to containers, which is compose and
data that is not on a volume.

It refuses without --container-path-unproven, and that flag is the honest
part of this change. Every test drives a fake docker. That proves the right
commands are assembled and proves nothing about whether a real image reads
the config it is handed -- which is the exact limit ARCHITECTURE.md section
4.8 records about the rollback code that was deleted for being tested only
against fakes. A doc note seemed too quiet for a tool that stops a mail
server, so it is a flag nobody reaches without being told.

The converted config reaches the container through the data volume. It is
written under the host side of whichever mount covers --data-dir and named
on the container side, because cutover recreates a container with the mounts
it had and cannot invent a new one for a config file. --data-dir therefore
names the path inside the container, which preflight already says when it
matches no mount.

PatchPaths stays unused, deliberately. Its documented purpose is pointing a
rehearsal at a sandbox; a real container's dumped settings already carry
container-side paths, because they come from the live server rather than
from a file on this host.

The preflight test that asserted docker was refused outright now asserts
the replacement rather than being deleted -- "docker is allowed through
here" is the thing that would be wrong to regress. Its fixture had to make
--data-dir both a real host directory and one the fake container mounts,
since disk-space stats it and container-data-volume wants it covered.

README gains the container section and, at the top, the note that this is
ihasmail's companion.

ARCHITECTURE.md

@@ -834,16 +834,26 @@ happens to need them. `preflight.DeploymentKind` is a type alias for
   §4.5 lists exactly which two details are inferred. A smoke test against a
   real 0.16 instance would settle both, and would let this step be promoted
   from "warns on failure" to a hard check.
-- **Docker is implemented but not yet wired to the CLI.** Preflight
-  inspects a container and reports what stands in the way; stage pulls and
-  verifies an image; the recovery cycle runs in a throwaway container
-  against the live data; and cutover recreates the container, refusing one
-  whose definition it would not carry across intact. What is missing is
-  `run` passing those options and preflight lifting its refusal for the
-  containers now handled. Compose stays refused deliberately: recreating a
-  compose-managed container out from under compose leaves the container and
-  the compose file disagreeing, and the next `compose up` reverts the
-  migration.
+- **Docker is wired end to end and has never met a real Stalwart image.**
+  Preflight inspects a container and blocks on what stands in the way;
+  stage pulls and verifies an image; the recovery cycle runs in a throwaway
+  container against the live data; cutover recreates the container,
+  refusing one whose definition it would not carry across intact. Every
+  test drives a fake `docker`, which proves the right commands are
+  assembled and proves nothing about whether the image reads the config it
+  is handed - the same limit §4.8 records about the deleted rollback code,
+  and the reason `run` refuses a container without
+  `--container-path-unproven`. A rehearsal on a clone, then a real
+  migration, is what would retire that flag.
+  Compose stays refused deliberately: recreating a compose-managed
+  container out from under compose leaves the container and the compose
+  file disagreeing, and the next `compose up` reverts the migration.
+- **The converted config reaches a container through the data volume.**
+  `run` writes it under the host side of whichever mount covers
+  `--data-dir` and names it on the container side, because cutover recreates
+  a container with the mounts it had and cannot invent a new one for a
+  config file. That is an inference from how the mounts must line up rather
+  than something a real deployment has confirmed.
 - **Cutover ignores systemd drop-ins.** It rewrites only the main unit
   file, so an `ExecStart` or `Environment` override in
   `/etc/systemd/system/stalwart.service.d/*.conf` is invisible to it -