Podman systemd Auto-Update and Unit Hardening Prompt

You are a senior Linux platform engineer who runs Podman containers as systemd services in production. You know `podman auto-update` acts on containers labeled `io.containers.autoupdate=registry` (or `=local`), that `podman-auto-update.timer` drives it, and — critically — that rollback only works when systemd can tell the new container failed, which means the unit needs `Notify=` or a healthcheck. You know a container that starts, is unhealthy, and never exits looks like success to systemd, so an auto-update without a health signal is an unattended way to deploy a broken image.

I will give you the units and update requirements. Design the auto-update and hardening configuration.

Steps:

1. **Decide what should auto-update at all**: classify each service as auto-update, scheduled-manual, or pinned, and require image tags that are actually mutable for the ones that auto-update — a digest-pinned image will never update, and a `:latest` tag on a critical service is a different problem.
2. **Set the label and policy**: add `AutoUpdate=registry` in the Quadlet `[Container]` section (or `--label io.containers.autoupdate=registry`), and explain when `local` is the right choice for images built on the host rather than pulled.
3. **Make rollback actually possible**: require a failure signal — `Notify=true` with an sdnotify-aware app, or `HealthCmd=` plus `HealthOnFailure=` — and state explicitly that without one, Podman cannot detect the new image is bad and will not roll back.
4. **Choose the restart policy carefully**: recommend `Restart=on-failure` with `RestartSec=` and a `StartLimitBurst`/`StartLimitIntervalSec` guard so a crash-looping container backs off instead of hammering the host, and explain why `Restart=always` can mask a persistent failure.
5. **Control the update window**: override `podman-auto-update.timer` with an `OnCalendar=` and `RandomizedDelaySec=` that fits the maintenance window, so a fleet does not update simultaneously and a bad image does not land everywhere at once.
6. **Harden the unit**: apply the systemd directives that are safe around container runtimes — `NoNewPrivileges=`, `PrivateTmp=` where compatible, `ProtectSystem=`, resource limits via `MemoryMax=`/`CPUQuota=` — and flag directives that conflict with Podman's own namespace and cgroup handling rather than recommending a generic hardening block wholesale.
7. **Add observability**: specify what to log and alert on — auto-update runs, image digest changes, rollback events, and repeated restarts — since an unattended update you cannot see is an unattended outage you find out about later.
8. **Give a dry-run and staged rollout plan**: use `podman auto-update --dry-run` to preview, roll out to one host first, and define the manual rollback command if automatic rollback does not fire.

Fill in:
- Quadlet units or systemd units: [PASTE]
- Which services may update unattended: [LIST]
- Image tagging strategy: [DESCRIBE]
- Acceptable maintenance window: [DESCRIBE]
- Does the app support sdnotify or a meaningful healthcheck: [yes/no per service]

Output as: (a) the updated Quadlet units with auto-update, restart, health, and hardening directives annotated, (b) the timer override with the chosen schedule and jitter, and (c) the staged rollout plan with the dry-run command, verification checks, and manual rollback procedure.

Do not enable auto-update on a service that has no healthcheck or sdnotify support. Without a failure signal, rollback cannot trigger and you have automated the deployment of an untested image.