feat(stacks): map host devices into stack containers from the UI (ADR-0030)

[swimmesberger]

What

Host devices (e.g. /dev/dri/renderD128 for GPU transcoding) can now be mapped into a stack's containers from the stack's Settings tab, without the devices: key ever appearing in the product's repository compose file.

• ADR-0030 documents the decision, including the deliberate precedence inversion: on a container-path collision the Watchtower mapping wins over the repo's entry, because device paths are per-host facts.
• StackDeviceMapping entity + stack_device_mappings migration, keyed by compose service name so rows survive redeploys.
• DeviceMappingPlan — the runtime-neutral policy half (ADR-0010 seam rule, mirroring ImagePinPlan): a mapping naming a service the resolved project lacks becomes a deploy-log warning, never a failed deploy.
• ComposeOverrideFile.Render gains a third plan and emits a devices: list in Compose's host:container[:permissions] string form. Compose merges devices: by container path, so override entries append to the repo's own. A stack with no mappings renders a byte-identical override to before.
• stacks.getDevices / stacks.setDevices RPCs. The set is replaced atomically (the stacks.setEnv shape), validated — absolute paths, rwm permission subset, duplicate host paths and duplicate container targets refused — and audit-logged, since mapping a host device is a host-access grant.
• Settings-tab "Device mappings" editor (service / host device / optional container path / optional access), saved by the existing Save button only when actually edited.
• The deploy log names every applied device and every skipped mapping.

Why

Device paths are host-specific: which render node exists differs per machine, while the compose file is shared by every stack of the product (ADR-0026). Committing them breaks hosts without the device; env-var pass-through still forces the stanza into the repo. The ADR-0012 generated override is the one place that can add them per stack without touching the repository.

Reviewer notes

• Out of scope by decision: template-level defaults and NVIDIA gpus/CDI (deploy.resources.reservations.devices is a different mechanism).
• ADR numbered 0030: 0029 is claimed by the blue-green ADR on its own branch.
• rpc-schema.json is regenerated (154 methods).

Testing

• New DeviceMappingPlanTests + ComposeOverrideFileTests device cases; full suite green (1896/1896).
• Verified live against the dev instance: editor round trip (save → RPC returns stored row with defaulted container path → reload rehydrates), and the validation refusals (relative path, bad permissions, duplicate target) — each errors without wiping stored rows.
• dotnet ef migrations has-pending-model-changes is clean; frontend tsc + lint clean.

[swimmesberger]

Second commit adds ADR-0031: "map host GPU(s)" as a per-service intent, resolved by probing the Docker host at deploy time.

• HostGpuProbe runs the backup helper image with /dev + /sys read-only and reads each render node's vendor/driver/PCI address/owning GID from sysfs (deterministic, no heuristics). Cached 5 min; a probe failure degrades to "no GPUs found" and never fails a deploy.
• The intent maps every mappable render node and emits group_add with the node's GID — closing the "device mapped but VAAPI still fails" permissions trap. NVIDIA nodes are deliberately skipped with a deploy-log note (toolkit/CDI is the working route; a bare device node fails inconsistently).
• A GPU-less host is a note, not a warning — same stack deploys everywhere, GPU where one exists.
• Same atomic stacks.setDevices replace + audit entry now carries both lists; new stacks.hostGpus powers the Settings read-out of what the intent would resolve to.

Verified live against the dev instance: the probe found Docker Desktop's virtio-gpu render node end to end (helper container → sysfs parse → UI read-out), and the intent round-trips through the Settings save. 1910/1910 tests green, model-changes check clean.