ci(release): verify-ci gate, dry_run, --locked, arm64 recollapse - #757

…762)

* ci(release): restore arm64 build timeout to 90m

The arm64 recollapse in #757 cut timeout-minutes 90->60 on the
assumption the single combined cross build would be faster. A post-merge
dry-run (run 29375276363) showed the cold-cache build runs ~65m and hit
the 60m cap, cancelling the job and skipping initramfs/release/stage. The
recollapse saves link time, not the dominant aws-lc-sys musl compile, so
restore the 90m headroom the split had.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ci(release): cache release builds with rust-cache (pruned, main-only save)

The two linux release builds cached the whole target/ (the largest in the
repo) via raw actions/cache into the 10 GB per-repo LRU shared with every
PR lane, so entries were evicted fast and release builds kept starting cold
— the arm64 dry-run ran ~65m from cold. Swap to Swatinem/rust-cache, which
prunes target/ to the dependency artifacts (the dominant aws-lc-sys compile)
so the entry is small enough to survive; save-if main-only stops branch and
dry-run dispatches from churning the budget. cross reads ~/.cargo and writes
target/ on the host, so rust-cache caches the arm64 build the same as a
native one. The 90m arm64 cap stays: a cache miss is still cold.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

release.yml's verify-ci gate (#757) requests checks: read at the job
level. When release.yml runs as a workflow_call from nightly.yml, it
cannot hold any scope the caller's permissions block doesn't grant, and
nightly.yml granted only contents: write and id-token: write — so every
scheduled run since #757 merged died at workflow compile time with
startup_failure (Jul 15 and Jul 16), cutting no nightly release. Manual
release.yml dispatches kept working because a directly-dispatched
workflow uses its own permissions, which is why this went unnoticed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…efore pushing unstable (#759)

* ci(release): smoke-test the shipped artifacts before publish

Prove the just-built RELEASE binaries actually run before publishing any of
them. Three new jobs download the uploaded artifacts by name, put the SHIPPED
binaries on PATH (never a fresh target/ build), and run the ONE shared session
e2e (scripts/session-e2e.sh — the same proof the CI lanes run):

- smoke-linux-amd64 (ubuntu): DM2 native minimald — the static-musl
  min/minimald boot a host daemon and pass the session e2e.
- smoke-linux-kvm (KVM-capable ubuntu): DM3 — boot a real microVM from the
  shipped native-glibc minvmd + shipped guest kernel/rootfs/initramfs +
  pinned gvproxy; libkrun is materialized from the upstream package (not
  shipped on Linux) via the shipped static mip.
- smoke-macos (self-hosted mini): DM1 — lay the SIGNED min/minvmd/libkrun.1.dylib/
  gvproxy + arm64 guest payload into the installer layout (libkrun.1.dylib a
  lib/ sibling of bin/, resolved via @loader_path/../lib) and boot the microVM.

A new skip-tolerant smoke-success aggregator (if: always(), fails only on
failure/cancellation) is added to the release job's needs, so a smoke failure
blocks every publish step while a skipped smoke-macos (RUN_MACOS_CI kill-switch)
reads as pass. Smoke has no !inputs.dry_run guard: a dry run builds, signs,
assembles, and SMOKES, then publishes nothing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(ci): grant nightly the checks scope its release call needs

release.yml's verify-ci gate (#757) requests checks: read at the job
level. When release.yml runs as a workflow_call from nightly.yml, it
cannot hold any scope the caller's permissions block doesn't grant, and
nightly.yml granted only contents: write and id-token: write — so every
scheduled run since #757 merged died at workflow compile time with
startup_failure (Jul 15 and Jul 16), cutting no nightly release. Manual
release.yml dispatches kept working because a directly-dispatched
workflow uses its own permissions, which is why this went unnoticed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci(nightly): smoke the shipped artifacts before advancing the channel

Move the three smoke jobs and their skip-tolerant aggregator from
release.yml into nightly.yml. The workflow_call jobs are part of the
caller's run, so each smoke job still downloads the just-built artifacts
by name and runs the one shared session e2e against the shipped bytes;
what changes is what the smoke gates. In release.yml it gated the
publish step of every release; here it gates promote-nightly, so a
failed smoke leaves the nightly channel pointing at yesterday's build
instead of blocking the release machinery itself. On a no-op night
(HEAD already staged) release and the smokes both skip and the channel
flip proceeds against bytes that were smoked the night they were cut.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): point the smoke VMs at the shipped gvproxy explicitly

minvmd never resolves gvproxy from PATH — resolve_gvproxy_path() honours
only MINVMD_GVPROXY_BIN, the installer bin dir ($MINIMAL_BIN /
~/.local/bin), and /usr/lib/minimal/bin. Renaming the shipped binary
onto PATH therefore left both VM smokes switchless: gvproxy resolution
is best-effort, so minvmd boots without guest egress and the in-guest
pkgs clone during session mint dies with 'Could not resolve host' —
the exact 10/10 failure the Jul 16 session-e2e-soak hit for the same
reason. Set MINVMD_GVPROXY_BIN on both session-e2e steps, as the KVM
and macOS lanes do.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(ci): stage gvproxy for the session-e2e soak

#760 deepened session-e2e.sh with the in-sandbox min add proof, whose
session mint clones the pkgs upstream inside the guest, and added
fetch-gvproxy + MINVMD_GVPROXY_BIN to the KVM and macOS lanes — but not
to nightly-tests' session-e2e-soak. With no gvproxy staged, minvmd
boots the VM switchless (resolution is best-effort and never errors),
the guest has no egress or DNS, and every one of the soak's 10
iterations dies with 'Could not resolve host: github.com' (first seen
on the Jul 16 scheduled run, the first after #760 merged). Stage the
pinned gvproxy and point MINVMD_GVPROXY_BIN at it, exactly as the KVM
lane does.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>