feat(release): ship the VM stack to Linux installs [blocked on pkgs#533] - #988

Linux installs shipped only min/mip/minimald + AppArmor, so own-ip was
dead on every installed Linux host (minimald resolved a switch binary no
install provides) and VM mode was macOS-only. Most artifacts already
existed in release.yml; they were never mapped to Linux components.

Linux now installs the same session stack macOS does:

- minvmd for BOTH arches. The arm64 build is new: setup-libkrun-linux
  is already arch-parameterized and ubuntu-26.04-arm already runs the
  arm64 lane, so it mirrors the amd64 steps.
- libkrun + libkrunfw, uploaded from the materialized prefix and staged
  under lib/ like the macOS dylib. Nothing produced a redistributable
  Linux libkrun before this.
- the guest payload (vmlinuz, rootfs.img, initramfs.cpio) for each arch,
  which release.yml already built for both and never staged.
- the switch binary, fixing own-ip on native (DM2) Linux.

scripts/rewrite-linux-linkage.sh is the Linux twin of the macOS @rpath
rewrite. Two RUNPATHs matter: minvmd -> $ORIGIN/../lib, and libkrun ->
$ORIGIN, the latter because glibc resolves a dlopen from a library
against the CALLING object's RUNPATH, so a shipped libkrun would
otherwise never find its libkrunfw sibling. It also hard-fails on a
soname bump rather than letting the lib/ dests go quietly stale.

The switch installs as `mingvproxy`, not `gvproxy`: the bin prefix is
~/.local/bin, which is on PATH, and podman/crc ship their own gvproxy
there — under the upstream name whichever landed last would win a PATH
lookup, in either direction. The bytes are stock gvproxy. install.sh
removes a bin/gvproxy left by a pre-rename install when its bytes are
still the ones we recorded writing, so an upgrade doesn't strand the
very collision the rename removes.

switch::installed_gvproxy_bin() is now the one definition of where an
install puts that binary; minimald defaults through it (it previously
only ever looked at the fixed system path, so a user-local install was
invisible to it) and minvmd delegates its lower tiers to it.

nightly's smoke-linux-kvm now consumes the SHIPPED libkrun from that
lib/ layout instead of materializing its own, with no LD_LIBRARY_PATH
and an explicit ldd assertion. Materializing would have masked exactly
the failure this lane exists to catch — the same shape of blind spot
that let #980 sit undetected (CI passed because it fetched gvproxy
itself and set GVPROXY_BIN).

Also drops the --network/--ingress rows from the min activate flag
table.

Refs: #980

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

shellcheck 0.9.0/0.10.0 flag `A && B || C` inside the record loop; the
locally-installed 0.11.0 relaxed that check, so the pattern passed here
and failed both the dedicated --shell=sh job and the shell_lint gate on
CI's older binary. Two plain guards say the same thing unambiguously.

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

Round one — defects in this PR's own new code:

- nightly's shipped-layout assertion could never pass. ld.so expands
  $ORIGIN but does not normalize the rest of the entry, so it reports
  <bin>/../lib/libkrun.so.1 verbatim; grepping for the canonical
  "$LIB/libkrun.so.1" never matched, which would have made the Linux VM
  smoke permanently red and blocked the nightly channel cut. Now
  canonicalizes both sides. Its sibling guard also piped into `grep -q`
  under `set -o pipefail`, where an early grep exit reports SIGPIPE and
  silently skips the check; ldd output is captured once instead.
- the gvproxy migration deleted a binary the same run had just
  installed. It keyed only off the PREVIOUS record, so a post-rename
  installer pointed at a still-shipping manifest — which channels
  advancing independently guarantees — removed the file every run,
  leaving no switch at all. Skips when this run installed a gvproxy
  component.
- that migration also got exactly one attempt (the record it reads is
  replaced immediately after) and swallowed a failed `rm` via an
  AND-list. A failure is now reported and the row carried forward so
  the next run retries.
- the soname check pattern-matched the whole resolved path, so a lib
  dir whose path contained "krunfw" compared libkrun against the wrong
  soname and aborted the release citing a bump that never happened.
  Explicit (file, soname) pairs now.
- the ephemeral-build-prefix guard applied only to minvmd. We prepend
  to libkrun's own RUNPATH rather than replacing it, so an upstream
  build path would ship to users unexamined. Same check both sides.
- the pre-swap daemon stop ran bare `min stop`, which resolves the
  DEFAULT provider (local-minimald on Linux) and so never stopped a
  running minvmd whose binary and libkrun were about to be replaced.

Round three — gaps the review is right about:

- make the linkage harness a real gate. `just test-linkage` was
  reachable from no CI lane, so a regression in the RUNPATH logic was
  green on all five aggregators. crates/common/tests/script_harnesses.rs
  drives it from the workspace suite, the same convention-discovered
  extension point shell_lint.rs uses (the workflow YAML is frozen).
- honour the pre-rename system-wide path. That directory is not on
  PATH, so the collision rationale never applied to it, and an operator
  who provisioned it has no install record to migrate — renaming
  without a fallback would silently break their own-IP.
- warn when the bin and lib prefixes are not siblings. They resolve
  from unrelated knobs (MINIMAL_BIN vs XDG_LIB_HOME) while minvmd finds
  libkrun through a binary-relative rpath, so a mismatched pair fails
  at autospawn with an opaque loader error.
- minimald's --help still promised the old fixed-path default.

Not addressed here, by design: the glibc floor and the unconditional
guest-payload download are product decisions, tracked separately
(gominimal/pkgs#533 covers musl libkrun for the former).

Refs: #980
Refs: https://github.com/gominimal/pkgs/issues/533

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

The legacy-path fallback added in the previous commit made three
assertions depend on what the host has under /usr/lib/minimal/bin: they
pinned DEFAULT_GVPROXY_BIN while the resolver returns the legacy path
when only that exists — so they failed on exactly the pre-rename hosts
the fallback was written to serve.

Split the resolution into `resolve_installed(bin_dir, system, legacy)`
with every probed location passed in, and drive the system-path branches
from temp dirs. Public API is unchanged. Both branches are now covered
deterministically (current wins when both exist; legacy when only it
does; current named when neither does; user-local beats both), which the
host-probing version could not express at all.

minvmd's tier-3 test asserts the result is under the system bin dir
rather than one exact path; `switch`'s own tests pin which branch wins,
and that test only needs to prove the tier-2 miss falls through.

Also documents the legacy branch on minvmd's resolver, which described
the renamed path as the only system fallback.

Reported by CodeRabbit on #988.

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

Spec 07 (installer):

- R4.1's prefix table omitted `lib` entirely, so read literally a `lib`
  dest was an unknown token that must exit with an error. Both platforms
  now ship `lib/` components.
- New R4.1a for the bin/lib sibling constraint. minvmd finds libkrun
  through a binary-relative rpath, but the two prefixes resolve from
  unrelated variables, so a host can set one and not the other. Records
  why the mismatch warns rather than fails: it breaks only VM-backed
  sessions, and diagnosing it at install time beats an opaque loader
  error at autospawn.
- R5.5 and its proof artifact said the daemon stop runs "exactly `stop
  --force`, once". It now runs once per backend, because bare `min stop`
  resolves the default provider and would leave a live minvmd holding
  its socket while its own binary and libkrun are swapped.
- New R6.1a for the renamed-component migration, which had four tests
  and no requirement to trace to. Covers the three rules that make it
  safe: skip when the manifest still ships the old name (a pre-rename
  manifest on an independently-advancing channel would otherwise have us
  delete the binary we just installed), report a refusal, retry a
  failure.
- R8.1's prune list omitted `lib`, which is shared like `bin` and so is
  rmdir'd-if-empty rather than purged.

Spec 02 (minvmd on Linux/KVM): "libkrun installation on Linux" said
libkrun is resolved from the host's system paths. That is now only the
dev/CI story — an installed host resolves nothing from the system and
loads the shipped libkrun through a binary-relative rpath. Splits the
two cases and states the consequences that are easy to get wrong: no
absolute build prefix may survive into a shipped binary, the lib prefix
must stay a bin sibling, and shipping libkrun sets a glibc floor
(gominimal/pkgs#533).

Spec 01: the libkrun-linking note described the absolute Homebrew rpath
as the whole story; marked as development-only with a pointer to 02.

Spec 08: two citations pointed at scripts/stage-release.sh:118, which
this PR's new COMPONENTS rows moved. Repointed by name instead of line.

Pre-existing drift found while surveying and deliberately NOT touched
here (it predates this PR and would bury the diff): spec 07's macOS
ad-hoc-codesigning narrative, spec 01/02's "Linux is a stub / autospawn
is a no-op" statements, and spec 03's source-build-gvproxy lines.

Raised by @twitchyliquid64 in review.

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

libkrunfw exists to carry a bundled GPL-2 guest kernel. minvmd supplies
its own via `ctx.set_kernel` from the shipped data/vmlinuz, so libkrunfw
is neither linked nor loaded — macOS has shipped libkrun alone all
along, which made Linux the odd one out rather than the other way round.

Drops the artifact, its uploads, its staging rows, and the machinery
that existed only for it:

- the libkrun `$ORIGIN` RUNPATH. Its sole justification was that
  libkrun dlopen()s libkrunfw by soname and glibc resolves that against
  the calling object's RUNPATH; with nothing to find, the entry is
  pointless. The shipped .so is now left verbatim and only leak-checked.
- the libkrunfw soname check, and with it the (file, soname) dispatch
  the last commit introduced — one library needs no dispatch, so the
  path-vs-basename bug it fixed is now unreachable by construction and
  its regression test went with it.
- the nightly smoke's libkrunfw placement.

This also removes the blocker recorded in gominimal/pkgs#533: musl's
static libc cannot dlopen, so "libkrun must dlopen libkrunfw" was the
thing standing between us and a static-musl minvmd — and therefore
between us and dropping the new Linux glibc floor entirely.

Caught by @twitchyliquid64 in review.

Refs: https://github.com/gominimal/pkgs/issues/533

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