Repair mozimo_net before Caddy restarts onto it

The deploy failed in the network role: the Caddy restart exited 125 with
"unable to find network with name or ID mozimo_net", and with Restart=always
and a 100ms delay the start limit was spent in under a second — taking every
other site this host serves down with it.

The network was gone, but mozimo-network.service was not: it is a oneshot with
RemainAfterExit=yes, so systemd kept reporting it active after the network had
been removed out of band. The generated Requires=mozimo-network.service looked
satisfied, so the flushed "Restart Caddy" handler started Caddy against a
network that no longer existed, and nothing recreated it.

- ansible/roles/network/tasks/main.yaml: daemon-reload after templating the
  unit so it can be started on a first deploy; ask podman (`podman network
  exists`) rather than systemd whether the network is really there; restart
  mozimo-network.service when it is not; confirm it exists before the handler
  flush, so a network that cannot be repaired fails the play rather than the
  host's reverse proxy.
- The Caddy restart condition includes the recreated case: a network that
  comes back keeps its name but not its identity, so Caddy's network namespace
  is stale even when neither template changed.
- ansible/README.md: the oneshot/stale-state trap and the manual recovery.

Verified on emily after recovering Caddy by hand: the play completes with
22 ok / 6 changed / 0 failed, and mozimo and vince run behind Caddy (TLS for
mozimo.in still waits on the DNS cutover).

ansible/README.md

@@ -52,6 +52,22 @@ central list:
 Removing a service is the reverse: delete the drop-in, delete the Caddyfile
 block, `systemctl --user daemon-reload`, and the network is no longer Caddy's.
 
+`mozimo-network.service` is a `oneshot` with `RemainAfterExit=yes`, so systemd
+keeps reporting it as `active (exited)` even if the network underneath it was
+removed out of band (`podman network rm`, `podman network prune`, a wiped
+`/run/user/<uid>`); restarting Caddy then starts it against a network that is
+not there, and Caddy's own restart loop takes *every* site on the host down
+with it. The playbook therefore asks podman (`podman network exists`) rather
+than systemd, and recreates the network before Caddy is restarted. To recover
+by hand:
+
+```bash
+ssh emily
+systemctl --user restart mozimo-network.service   # recreate mozimo_net
+systemctl --user reset-failed caddy.service
+systemctl --user start caddy.service
+```
+
 ## Migrating monoco → emily
 
 monoco is the current host: rootful Docker, data in `/var/lib/mozimo`, its own