Record what testing podman actually showed

0060 said the container runtime was a separate decision. It is now made, and
the reasoning is worth keeping because it is the opposite answer to the same
question one paragraph earlier.

Abstracting service managers is lossy -- systemd and OpenRC are different
models and LoadState has no equivalent. Container runtimes converged on one CLI
deliberately, so almost nothing is lost: checked against podman 6.1.0, run,
rm -f and docker's own template syntax for state and labels all work unchanged.
Only the probe differs. So: a two-entry lookup, not an interface.

The difference that is NOT in the CLI is the one that would have shipped
silently. Podman accepts --restart unless-stopped, records it, and has no
daemon to act on it -- containers do not return after a reboot unless
podman-restart.service is enabled, which by default it is not. Every command
reports success and the effect does not happen.

That belongs in the declaration rather than the host: a node using podman is
told to enable the unit. Which is what made the service shape's missing 'boot'
field visible, and it is now built.

02-DECISIONS/0060-the-host-is-built-per-operating-system.md

@@ -89,9 +89,24 @@ broken one.
   host ships as a package from the mesh's own repository
   ([ADR 0058](0058-delivery-ends-in-a-declaration.md)), and a `.pkg.tar.zst` is an Arch artifact.
   A per-OS binary is consistent with what was already decided rather than an addition to it.
-- **The container runtime is left unresolved on purpose**, because it is not an OS split: Arch
-  runs docker or podman. Per-OS hosts answer the service and package managers and leave the
-  runtime a genuine choice *within* a host. That is a separate decision.
+- **The container runtime is a choice within a host, not an OS split** — Arch runs docker or
+  podman — and it is **detected, not declared**, because adoption keeps what the machine already
+  has. Two are supported.
+
+  This is the opposite answer to the one above, for a reason rather than by preference.
+  Abstracting service managers is *lossy*: systemd and OpenRC are different models, and
+  `LoadState` has no equivalent. Container runtimes deliberately converged on one CLI, so almost
+  nothing is lost — checked against podman 6.1.0, `run`, `rm -f` and docker's own template
+  syntax for reading state and labels all work unchanged. **Only the probe differs**
+  (`{{.ServerVersion}}` against `{{.Version.Version}}`), which makes it a two-entry lookup
+  rather than an interface.
+
+  **One difference is not in the CLI and would have shipped silently.** Podman accepts
+  `--restart unless-stopped` and records it, and has no daemon to act on it: containers do not
+  come back after a reboot unless `podman-restart.service` is enabled, which it is not by
+  default. Every command reports success and the effect does not happen. That belongs in the
+  **declaration** — a node using podman is told to enable that unit — rather than in the host,
+  which keeps the host dumb and puts the difference where a person can read it.
 - **A second operating system is now additive rather than a redesign** — write two appliers, ship
   a package. And it will be designed against a real machine rather than a guess, which is the
   point of not building the abstraction now.