Match the deploy system to hops and greatbear

menu-admin was the odd one out: it built from the working directory with a date
tag and a multi-arch manifest, deployed with `-e tag=`, and kept the Docker-era
container name. The other two apps build from `git archive HEAD` and tag with the
commit, so what runs on the host is exactly what git knows about; build only for
the architecture emily actually runs; and use one slug for the container, its
network and its data directory.

The build is now their three lines: `podman build --platform linux/arm64` from
`git archive HEAD`, tagged `:<commit>` and `:latest`, pushed with `podman push`
rather than a manifest. `deploy.sh` pushes the commit first, then refuses a dirty
tracked tree or a HEAD that is not origin/main — which is what makes the commit
tag trustworthy — takes the same `--force` and `--no-push`, and ends in the same
`-u tanshu ... -e image_tag=<commit>`. Its own lint/typecheck/test gate stays,
but behind `--checks`, so a plain deploy behaves as theirs does.

The registry credential moves into vars/default.yml and the role logs in, pulls
and logs out around it, as their roles do. The image is only pulled at deploy
time, so the unit keeps podman's default `Pull=missing` and a reboot never needs
the registry. This is the same plaintext credential the other two repos carry.

One real bug goes with it: the healthcheck gate ran before the handler that
restarts a changed unit, so a run that only changed the unit checked the stale
container. `meta: flush_handlers` before the gate is the fix the sibling repos
already made.

The container, network and data directory are all menu-<site> now. The dotted
Docker-era name and the NetworkAlias it needed are gone, so `podman logs
menu-<site>` and `systemctl --user status menu-<site>` are the same two commands
across all three apps. The Dockerfile keeps its name for the same reason: podman
reads it as readily as a Containerfile, and the siblings use that name too.

docs/adr/0009-rootless-podman-quadlets.md

@@ -2,8 +2,9 @@
 
 Each Site is deployed as a **rootless Podman** container managed by a systemd
 user unit (Quadlet) on `emily`, reached through the one shared Caddy unit rather
-than a long-lived rootful Docker container. The image is built by `podman` too,
-from a `Containerfile`. This matches how every other service on that host is
+than a long-lived rootful Docker container. The image is built by **Podman** too,
+from the committed tree, the same way the sibling `hops` and `greatbear` apps are
+built and deployed. This matches how every other service on that host is
 deployed, and it takes the deployment off Docker entirely.
 
 The app owns its whole serving path, so it needed the smallest deployment of the
@@ -19,13 +20,15 @@ and never has to be edited when a Site is added or removed.
 **Considered Options**: staying on rootful Docker on `monoco`, rejected because
 the fleet is moving and leaving one app behind means two runtimes and two Caddy
 configs to reason about; running rootful Podman, rejected because it keeps the
-same root-owned data and loses the plain-backup property; and naming the Quadlet
-unit after the container (`menu-app.<domain>`), rejected because the dots make
-the unit name awkward and the name fragile in DNS — the unit is `menu-<site>`
-while the container keeps its old name for the scripts that look it up.
+same root-owned data and loses the plain-backup property; and keeping the
+Docker-era container name `menu-app.<domain>`, rejected because a name with dots
+in it is a liability in DNS and it would have meant a second name (a network
+alias) for Caddy to proxy to. The inventory name is now the single slug for
+everything — container, network and data directory are all `menu-<site>`, so the
+two commands an operator needs are the same across all three menu apps.
 
-**Consequences**: the app is not published on a host port at all — only Caddy,
-on the shared Podman network, can reach it — and deployment, logs and restarts
-move from `docker` to `systemctl --user` / `podman`. The data root moves to
+**Consequences**: the app is not published on a host port at all — only Caddy, on
+the shared Podman network, can reach it — and deployment, logs and restarts move
+from `docker` to `systemctl --user` / `podman`. The data root moves to
 `~/podman-data/menu-<site>`, so each Site's content has to be copied across from
 `/var/lib/menu.<domain>` once, before DNS points at it.