ci: extract shared setup composites and the macOS linkage-rewrite script - #685

…facts

Four new composite actions dissolve copy-pasted setup blocks:

- setup-rust: free-disk + protoc + rust-cache preamble, previously
  inlined in ci.yml clippy AND duplicated inside core-tests
- setup-libkrun-macos: the brew slp/krun tap install, previously
  copy-pasted across ci-macos.yml and release.yml (the release job's
  separate dylib-existence check is dropped like ci-macos's was in
  #678: a failed brew install already fails the step, and a missing
  libkrun still fails loudly at link/rewrite time)
- setup-libkrun-linux: fetch-libkrun.sh + the LIBKRUN_PREFIX /
  LD_LIBRARY_PATH exports, previously duplicated between
  ci-linux-kvm.yml and release.yml's amd64 build
- guest-artifacts: the kernel + rootfs cache pulls, previously
  repeated in ci-macos.yml, ci-linux-kvm.yml, and release.yml

The two fetch composites retry 3x to absorb transient cache/network
hiccups; commands, arguments, and env are otherwise unchanged.

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

Three latent bugs surfaced by review once the previously-inline code
became a parameterized, reusable script:

- otool -L's header line is the binary's own path; a binary living
  under a path containing "libkrun" (e.g. a throwaway CI copy) would
  false-match and silently skip the real rewrite. Skip the header
  (NR>1).
- install_name_tool -rpath errors when the bare @loader_path entry is
  already gone, so a second run on an already-rewritten binary
  hard-failed. Retarget only when the dev rpath is present.
- set -o pipefail aborted the `current=` capture before the annotated
  "no libkrun load command" diagnostic could fire when otool itself
  fails. Guard the capture with || true; the -z check handles both.

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

Integrates #672 (per-VM /dev/vdb volume) with the composite extraction:

- The two copies of main's new libkrun >= 1.19.0 (krun_add_disk3)
  symbol check in ci-macos.yml fold into the setup-libkrun-macos
  composite's verify step, so the release mac build gets it too.
- The KVM lane's new krun_add_disk3 assert now reads LIBKRUN_PREFIX
  (published by the setup-libkrun-linux composite) — the KRUN_PREFIX
  env it referenced was retired with the composite extraction, so the
  auto-merged step would have probed an empty path.
- main's crates/minimald/** path additions and the Session-E2E VM
  reap step (#588 fix for the merged e2e job) are kept as-is.

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

Actions history for both VM lanes (last ~200 runs each, plus the
first attempts of every manually re-run run) records not a single
failure in the retried steps: the kernel/rootfs cache pulls, the
libkrun prefix fetch, and the gvproxy download have never failed.
The retries were insurance without receipts; remove them and the
now-unused scripts/ci/retry.sh, returning the composites to plain
extractions of the original steps (the mip prebuild and input
pre-validation existed only to keep deterministic work out of the
retry loops, so they go too).

The transient failures the history DOES show are apt-get installs —
the only main-branch KVM lane failure in the window and both of its
manual reruns died in "Install build dependencies". Retry belongs
there if anywhere, left for a separate change.

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

The __krun-vmm-only reap from #672 is insufficient: main run
29032763009 — on the very commit that added it — still failed the
cold `minimal ls` with `ssh connect: Disconnected` against a fully
healthy guest (READY emitted, minimald listening on vsock:2222, no
connection ever accepted): the #588 bridge wedge. The remaining
leftover is the host gvproxy switch, which minvmd owns and
Guest::drop never kills; the failing runs' proxy-publish WARN
corroborates a lingering gvproxy. Reap any stray minvmd first (so
nothing respawns), then the VMM and gvproxy.

The proper fix — the session harness reaping its own process group —
stays tracked under #588; this keeps the merged e2e job's steps
isolated in the meantime.

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

Resolves against #692, which introduced the materialize composite
(channel-released prebuilt mip; no source build) for the guest
kernel/rootfs pulls — superseding this branch's guest-artifacts
composite, which wrapped the same call sites around
scripts/fetch-artifact.sh. Resolution: adopt materialize at every
conflicted call site (ci-macos artifacts, ci-linux-kvm, release
fetch-release-guest-artifacts, including main's removal of the now
unneeded toolchain/protoc/cargo-cache steps in the release fetch
job), delete the guest-artifacts composite, and point the VM lanes'
composite path filters at .github/actions/materialize/** instead.

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