ci: parallelize image builds with tests; fix cargo-chef layer caching

[popen2]

Why

Two structural inefficiencies in the backend release pipeline make CI slower than it needs to be. This addresses both.

1. Image builds were serialized behind clippy + tests

The image matrix declared needs: test, so neither arch build could start until the test job (cargo clippy --release + cargo test --release) finished. But the test job compiles for the host gnu target while the image builds compile for musl (x86_64/aarch64-unknown-linux-musl) — three different target triples that share zero compiled artifacts. So the gate added the entire clippy+test duration to the critical path with no reuse benefit.

Change: drop needs: test from image so tests and the two native-arch builds run concurrently. Critical path goes from test + build to roughly max(test, build).

Correctness is preserved by re-gating where it matters: the merge job — which creates the published multi-arch tag — now needs: [image, test], and release still depends on merge. So no tagged image is ever published when linting or tests fail. On a tag push the per-arch jobs may push untagged digests before tests finish, but those stay dangling and unreferenced unless merge runs.

2. cargo-chef was a no-op in CI (deps recompiled from scratch every run)

The Dockerfile builder stage mounted /build/target (and the cargo git/registry dirs) as BuildKit type=cache mounts. But:

• BuildKit cache mounts are not part of the image layer and are not exported by cache-to: type=gha.
• setup-buildx-action creates a fresh docker-container builder each run, so those mounts start empty every time.
• cargo-chef depends on the cook step's compiled deps being captured for reuse. On the common case (source changed, deps unchanged), the cook layer was a cache hit and got skipped — without repopulating the empty mount — so the final cargo build recompiled every dependency from scratch, on each arch, every run.

Change: remove the cache mounts so the cook step's output lands in the layer filesystem, where Docker's layer cache captures it and cache-to: type=gha,mode=max (already scoped per arch) persists it across runs. Now a source-only change restores the cook layer from cache and rebuilds only the workspace crates — which is the whole point of cargo-chef.

Verification / caveats

• I can't measure Actions run timings or read build logs from where I'm working, so the timing claims are structural, not measured. The cache fix is verifiable from a build log: on a docs-only change, the cook step should now be CACHED instead of recompiling dependencies.
• The cook layer now carries the dependency target/ dir, so the per-arch GHA caches grow. With two arch scopes this could approach the 10 GB repo cache budget; worth watching. Worst case (eviction) is no worse than today's effectively-cold builds.

Each concern is a separate commit if you'd prefer to take them independently.

---

Generated by Claude Code