Task: Generate Quadlet (podman) units for remote hosts from the same dependency graph

Extend compass systemd (currently generate~/~deploy for plain local --user units, in projects/ores.compass/src/systemd_generate.py) with a second renderer, compass systemd quadlet, that reads the same service_definition~/~service_dependency tables and emits Quadlet .container unit files for podman/remote hosts (e.g. Newton) – one source of truth (the DB dependency graph), two renderers (local plain-systemd, remote Quadlet). Reuse the same After=~/~Requires= ordering derivation already written for the plain-systemd path, and wrap the generated units in a per-environment .target the same way. Add a compass systemd quadlet-deploy subcommand that copies the rendered units to a target's ~/.config/containers/systemd/ and runs systemctl --user daemon-reload && start there. Reuse the podman --sdnotify=healthy~/HEALTHCHECK plumbing from the IAM pilot (PR #1787) so Quadlet's own readiness gating (via ~Type=notify~/–sdnotify=healthy~) lines up with the same sd_notify(READY=1) contract the plain-systemd units already use.

Scope boundary (decided after discovering the sibling Offload service and DB runtime to a WSL host over SSH story already owns adjacent BACKLOG tasks for this exact area): this task owns rendering the Quadlet units and copying/starting them on a reachable host given already-built images – it does NOT build new compass tooling for building/saving/transferring container images to a remote host (that is Add compass tooling to build, stage, transfer, and deploy service-runtime images to a remote host's job), and it does NOT roll the full 18-service fleet out to Newton (that is Get all 18 services running end-to-end on Newton's job). End-to-end verification here reuses the already-built localhost/ores-iam-pilot:local image, transferred manually via podman save~/~ssh ... podman load (the ad-hoc sequence the sibling story's tooling task will later formalise), not new compass image machinery.

• compass systemd quadlet (or equivalent) renders one Quadlet .container unit per (service, environment) pair from service_definition~/~service_dependency, plus NATS, mirroring the plain-systemd generator's one-file-per-service approach – no manually-maintained podman pod/compose spec.
• Generated units carry After=~/~Requires= ordering derived from the same dependency graph as the plain-systemd path (single source of truth, not duplicated/hand-reconciled logic).
• Units are wrapped in a per-environment .target so systemctl --user start/stop ores-<env>.target works identically to the local plain-systemd deployment mode.
• compass systemd quadlet-deploy copies the rendered units to a target host over SSH and brings the target up there (systemctl --user daemon-reload && start), without touching another environment's or another remote host's units.
• Readiness gating on the remote/podman side matches the local sd_notify(READY=1) contract (Quadlet --sdnotify=healthy / Type=notify), reusing the IAM pilot's HEALTHCHECK work (PR #1787) rather than reinventing it.
• Verified end-to-end locally (this checkout's own podman/Quadlet, the same generator output that would run on any Quadlet-capable host) for the IAM pilot service, following the same "prove it on one service first" pattern the earlier per-service-container pilot task used – reaches podman ps ``healthy`` and ~systemctl –user status`` ``active (running)``.
• Genuinely deploying to Newton itself is deferred: it needs docker/.env and the built image physically present there, which is exactly the image-build/transfer tooling this task deliberately does not build (see Goal's scope boundary) – compass systemd quadlet-deploy --host is written and ready for when that lands.
• Out of scope, left to the sibling offload-to-WSL-host story's own tasks: compass tooling for building/saving/transferring images, and rolling the full 18-service fleet out to Newton.

Extended projects/ores.compass/src/systemd_generate.py with a second family of renderers (render_quadlet_singleton_unit, render_quadlet_wrapper_units, render_quadlet_nats_unit, render_quadlet_target) reusing the existing fetch_service_definitions~/~fetch_dependencies~/~_substitute_args plumbing, plus compass systemd quadlet (render) and compass systemd quadlet-deploy [--host] (install/start, locally or over SSH) subcommands. Verified against podman-user-generator -dryrun and a real local start of the IAM pilot service, fixing three real bugs found along the way (see Notes).

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.

Shipped compass systemd quadlet~/~compass systemd quadlet-deploy [--host] (projects/ores.compass/src/systemd_generate.py), a second renderer over the same service_definition=/=service_dependency dependency graph the plain-systemd generator already reads, emitting Quadlet .container units (one per service+environment, plus NATS) with the same After=/Requires= ordering and a per-environment .target. Verified end-to-end locally: the IAM pilot service reaches podman ps ``healthy`` and systemctl --user status ``active (running)``, with real NATS handler registration and a ``Service ready.`` log line. Found and fixed three real bugs along the way (unit- name collision with the plain-systemd path, ``${ORES_NATS_URL}`` never resolving, and the "Newton storage EIO" finding reproducing locally too) – see Notes for each.

Deliberately scoped to rendering and local/SSH install, not to building/transferring container images or rolling the fleet out to Newton – both already tracked as BACKLOG tasks in the sibling Offload service and DB runtime to a WSL host over SSH story, discovered mid-task and deliberately not duplicated here.