ci: stop container builds starving the runner fleet

[thedancingdeveloper]

Three pushes to main between 04:38 and 05:17 left three Container images builds running at once — one on each Node B runner — for 80+ minutes. CI, Dashboard demo and secscan queued behind them, while proxmox-gha-public-rust and wsl2-gha-public-rust sat idle and ineligible.

Nothing was looping. Every run traced to a real push or PR. The builds are genuinely that slow, and nothing stopped them accumulating.

The asymmetry that made it look wedged

Event	platforms	push	Outcome
pull_request	linux/amd64	no	finished in minutes (#48, #50)
push to main	linux/amd64,linux/arm64	yes	80+ min, still running (#47, #49)

arm64 is emulated through QEMU, twice over because there are two images, with caching disabled entirely.

Changes

1. concurrency groups on CI, Container images and Migration policy — a new push supersedes the in-flight run for that ref. Dashboard demo already had one.
2. arm64 restricted to tags. Pushes to main build amd64 only; tags still get both.
3. Registry-backed build cache replacing cache-from/to: ''. Caching had been switched off to work around a BuildKit wedge during GHA cache finalization, so every build has paid full cost ever since. type=registry avoids the path that wedged, and unlike type=local it survives job-completed.sh wiping the workspace after each job. Gated on the same condition as the ghcr login, since writing needs auth.
4. runs-on: [self-hosted, publish] instead of [..., docker]. All three Node B runners advertise docker, but only the publish pair has a DinD sidecar — run #49 was dispatched to node-b-gha-public-rust, which has no Docker daemon. See gap 4 in the ops repo's docs/github-actions-runner-gaps.md.

Note on required checks

build and policy are required. Job names are unchanged, so branch protection is unaffected. Change 4 narrows build to the 2 DinD runners — correct, since it is the only place it can actually run.

Full context: docs/2026-08-18-runner-fleet-status-and-ci-policy-findings.md.