Runner cache volumes: commit master archive + digest atomically (immutable generation-keyed objects)

Deferred hardening from #11788 (per-account macOS runner cache volumes, spec #76). Tracking this review thread; kept open at the reviewer’s request.

Problem

Every promoted job uploads its cache-volume master to the same mutable object key under runner-volume-masters/{account_id}/... and reports its inventory digest in a separate report_volume_head request. Two jobs for the same account can interleave:

upload A → upload B → report B → report A

leaving B’s bytes paired with A’s digest and generation. Hosts then either keep redownloading (digest never matches what they materialize) or accept coordination metadata that does not describe the stored archive.

This is compounded by the fact that the reported digest hashes the sorted top-level entry names (Binaries / Manifests / ProjectDescriptionHelpers / Plugins), not the file bytes — it is a change-detection signal by design, so it cannot catch a bytes-vs-metadata mismatch on its own.

Proposed fix

Either:

• Publish to immutable, generation-specific object keys and atomically advance the account HEAD to that (key, digest) pair, so a stale/interleaved report can never repoint HEAD at bytes it didn’t produce; or
• Make the head report conditional on the uploaded object version (e.g. S3 versionId / If-Match), rejecting a report whose object version isn’t the one HEAD is being advanced to.

Scope

• server: Tuist.Runners / VolumeHeads (object key layout, HEAD advance).
• tart-kubelet: materialize/convergence digest verification (internal/podagent).

Trust-boundary context: the current PR fully excludes untrusted fork jobs from the cache (no grant, no volume, discard on host), so this is a same-account correctness/consistency hardening, not the fork trust boundary.

No GitHub comments yet.