Task: Roll out per-service containers to the remaining 17 services

Apply the proven IAM pilot pattern (parameterised docker/service-runtime.Dockerfile + stage-runtime.sh --service + per-service HEALTHCHECK) to the other 17 service binaries, replace the single-container fleet with one podman pod/compose spec running 18 per-service containers wired via the dependency-graph generator and podman-events watcher (both separate tasks), and verify the full fleet reaches steady state end-to-end – the story's own original acceptance criterion.

• All 18 service binaries run as PID 1 of their own per-service container, not spawned by the controller.
• The full fleet starts, reaches steady state – all 18 services healthy, 22 containers counting ores.compute.wrapper's 5 replicas (each its own container in this architecture, vs. 5 child processes under one controller previously) – and survives killing/restarting one service container without taking down the others.
• Startup ordering and readiness gating come from the orchestration layer (via the dependency-graph generator task), not from process_supervisor.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

ABANDONED 2026-07-31: this task's plan (one podman pod/compose spec running 18 per-service containers, wired via a separate podman orchestration layer) predates the story's pivot to systemd as the single orchestration substrate (see story.org's Goal, and the dependency-graph-generator task's scope expansion). Rolling out per-service containers to the remaining 17 services is now the Quadlet generator task's job: it reads the same service_definition~/~service_dependency tables the plain-systemd generator already does and renders Quadlet .container units – already-parameterised (docker/service-runtime.Dockerfile's ARG SERVICE_NAME) – for every service, not just IAM. No separate manual pod/compose rollout is needed.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.