fix(ci): build multi-arch wifi-densepose image (linux/arm64 was missing, closes #625)

[MackDing]

Fixes #625. (Same crash class as the closed-unmerged #136.)

Bug

README.md:44 advertises Docker: multi-arch amd64 + arm64, and PR #547 ("refresh Docker publish") promised multi-arch as part of the :latest rebuild plan, but .github/workflows/sensing-server-docker.yml:100 only sets:

platforms: linux/amd64

So ruvnet/wifi-densepose:latest on Docker Hub today is amd64-only:

$ curl -s https://hub.docker.com/v2/repositories/ruvnet/wifi-densepose/tags/latest/
last_updated: 2026-05-14T17:35:04Z
images:
  arch=amd64    os=linux       size=34509901
  arch=unknown  os=unknown     size=1496      # attestation layer, not arm64

Reproduction (from #625, Mac M3 Pro / macOS Tahoe 26.4.1):

$ docker pull ruvnet/wifi-densepose:latest
Error response from daemon: no matching manifest for linux/arm64/v8 in the
manifest list entries: no match for platform in manifest: not found

Fix

Standard buildx multi-arch recipe — 2 small changes to sensing-server-docker.yml:

Change	Why
Add docker/setup-qemu-action@v3 before setup-buildx-action@v3	QEMU user-mode emulation lets the ubuntu-latest (amd64) runner cross-build the linux/arm64 layer. Without it, buildx refuses unknown platforms.
platforms: linux/amd64 → platforms: linux/amd64,linux/arm64	Actually publish the arm64 layer the README + #547 promised.

docker/Dockerfile.rust needs no changes — verified arch-agnostic:

• No --target flag on cargo build
• No target.x86_64-* / target.aarch64-* sections in any Cargo.toml
• Only native build-deps is cc = "1.0" (already cross-aware)

Smoke tests are unaffected: they docker pull on ubuntu-latest, which auto-selects the amd64 entry from the multi-arch manifest. Multi-arch manifests are transparent to single-arch consumers.

Diff

+11 / -1, one file:

+      - uses: docker/setup-qemu-action@v3
+
       - uses: docker/setup-buildx-action@v3
...
-          platforms: linux/amd64
+          platforms: linux/amd64,linux/arm64

Alternatives considered

• Native arm64 runner (ubuntu-24.04-arm) instead of QEMU emulation. Faster (~3-5× for a Rust workspace this size) but requires a strategy.matrix over {runs-on, platforms} + a docker/manifest-action join step. ~50 lines of churn vs. 11. Happy to do this in a follow-up if build time on arm64 becomes painful — but the cheap one-line fix unblocks macOS docker issue #625 today.
• Cross-build with cross / --target aarch64-unknown-linux-gnu in the Dockerfile. Would avoid QEMU runtime emulation but means restructuring the Rust build stage. Bigger blast radius, scope-creep for what is a workflow-config bug.

Scope

Only touches .github/workflows/sensing-server-docker.yml — the workflow #625 is about. nvsim-server-docker.yml:59 has the identical platforms: linux/amd64 bug (different image, separate concern); happy to file a follow-up PR for that one if useful — kept out here for review-clarity.

One observation, not part of this fix

The last 5 runs of sensing-server-docker.yml have failed at the Log in to Docker Hub step (looks like DOCKERHUB_TOKEN rotated/expired). Once that secret-side issue is resolved, the next push to main will produce the first true amd64 + arm64 manifest — and #625 / #136 will close. Pointing this out so the green-CI signal on this PR doesn't get misread as "fix works"; the only way to fully verify the merged behaviour is the post-merge push.

Happy to iterate on commit message, scope, or the QEMU-vs-native-arm-runner question.

[ruvnet]

Right diagnosis — README badge advertises arm64 + Apple Silicon users hit no matching manifest for linux/arm64/v8. QEMU setup + linux/amd64,linux/arm64 platforms in buildx is the standard fix and the only thing needed since Dockerfile.rust is arch-agnostic (no --target flag, no platform-specific RUN). Closes #625 + the older #136. Merging.