Flaky CI Failure: Pin to cachix fails — mls-validation-service.tar.gz not in binary cache (aarch64)

## Flaky CI Failure: Pin to cachix fails — mls-validation-service.tar.gz not in binary cache (aarch64) **Workflow:** Cache all Nix Outputs **Failed run:** https://github.com/xmtp/libxmtp/actions/runs/25406887246 **Commit:** 601a29b31d035dfa75be2c3d562392341803d2d6 **Failed jobs:** validation-image-aarch64 ### Summary The `validation-image-aarch64` job built the MLS validation service image successfully but then failed at the "Pin to cachix" step with HTTP 400. Cachix reported that the Nix store path for `mls-validation-service.tar.gz` was not present in the `xmtp` binary cache, so it could not be pinned. The two `build` jobs (x64 and macOS arm64) both succeeded. KVM was also unavailable on the runner (`Failed to open the device 'kvm': Invalid argument`), though that appears non-fatal. ### Error Details ``` cachix: FailureResponse Request POST https://cachix.org/api/v1/cache/xmtp/pin Response: Status 400 Bad Request Body: { "error": "/nix/store/73xxinnyflyjcp75242xswzdxjfnw5ny-mls-validation-service.tar.gz not in binary cache xmtp. Run `cachix push xmtp /nix/store/73xxinnyflyjcp75242xswzdxjfnw5ny-mls-validation-service.tar.gz`" } ##[error]Process completed with exit code 1. ``` Secondary (non-fatal) warning: ``` ##[group]Enabling KVM support KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm" Failed to open the device 'kvm': Invalid argument KVM is not available ##[endgroup] ``` ### Analysis The workflow builds the `mls-validation-service` Docker image as a Nix derivation and then attempts to pin it in the `xmtp` cachix binary cache. The pin step fails because the built store path (`73xxinnyflyjcp75242xswzdxjfnw5ny-mls-validation-service.tar.gz`) was never pushed to cachix — either the cachix push daemon missed it, the push failed silently, or the newly-built derivation hash changed and the push step didn't complete before the pin was issued. This is a **CI workflow / caching configuration failure**, not a code regression. Possible root causes: 1. The aarch64 build produces a new derivation hash not yet in the cache, and the cachix daemon's push did not complete before the pin step ran. 2. KVM unavailability may affect how the image is built (different store path hash), producing a path the cache doesn't know about. 3. The pin step races with the background cachix push daemon. The fix is likely to ensure the push completes before the pin is attempted, or to make the pin step conditional on a successful push. --- *Reported by [Flaky Failure Watcher](https://github.com/xmtp/libxmtp/blob/main/.github/workflows/flaky-failure-watcher.yml)*