Ask the container what it is running

Preflight's first check ran `--version` on --binary. A container-only host
has no such file, so the check failed, and because it is first, nothing
downstream ever ran — including every container check that exists to
decide whether that container can be migrated at all. The container path
was unreachable on exactly the hosts it is for.

A host that happens to have a binary is the worse case, not the better
one: a stray /usr/local/bin/stalwart from an older install answers
confidently with a version nothing is running, and the whole migration
plan is derived from that number.

The source version now comes from running the image the container is on,
by ID rather than by the tag it was started from, using the same command
and the same fallback stage already uses for the target image — the two
have to agree about what a Stalwart image reports or the source and
target could be read by different rules. Verified against a real
stalwartlabs/stalwart image, not only the fake.

Deployment kind is detected once and shared, rather than asked again by
the check that reports it. Two answers for one run is not a thing this
should be able to produce.

The same reasoning retires preserve-binary on a container: there is
nothing on this host to move aside, and the equivalent is already
guaranteed, since cutover renames the old container and never prunes the
old image. Renaming a stray binary would have preserved something nothing
was running.

ARCHITECTURE.md

@@ -304,6 +304,19 @@ against an already-migrated store.
   while the server is still running, and again at cutover: the answer does
   not change between them, and only one of the two points can refuse
   without having already cost an outage.
+- What is *running* is a property of a container's image, not of anything
+  on this host. Preflight's first check used to run `--version` on
+  `--binary`, which a container-only host does not have - so the first
+  check failed and nothing downstream ever ran, including every container
+  check. A host that happens to have a stray binary is worse than one that
+  does not: it answers confidently with a version nothing is running. The
+  source version is now read by running the image the container is on, by
+  ID rather than by the tag it was started from, with the same command
+  §4.3 uses for the target image so the two cannot disagree about what a
+  Stalwart image reports.
+- For the same reason there is no old binary to move aside on a container.
+  Its equivalent is already guaranteed: the old container is renamed and
+  the old image is never pruned.
 - What a container *inherits* from its image is not what it *overrides*,
   and only the override is the operator's. `docker inspect` reports
   `User`, `Cmd` and `Entrypoint` either way - a container off the official