ci(vm): publish immutable runtime artifacts and automate Nix updates #4600

User Story

As an OpenShell contributor building local Debian artifacts for tmachine qualification, I need the VM runtime inputs selected by a checkout to remain available with matching checksums so that unrelated packaging work and clean builds remain reproducible.

Description

Publish the VM runtime under immutable identifiers and automate proposals to update the runtime reference and hashes in nix/pkgs/vm-runtime.nix together.

The current vm-runtime release is mutable: .github/workflows/release-vm-kernel.yml moves the tag and replaces the archives at the same URLs. Nix pins the contents of those URLs by hash. Replacing the archives breaks that URL-and-hash pairing until the hashes are updated manually; updating main does not repair older checkouts.

Each published runtime selected by Nix should remain available unchanged. Successful publication should propose an update PR for all supported platforms, with checks that fetch the artifacts, verify their hashes, and build the runtime derivations. A moving convenience alias may remain, but reproducible builds should select an immutable release.

Context

This surfaced while adding local Debian artifact tooling in #4598. Building the VM driver with its embedded Linux runtime exposed stale Linux archive hashes even though the VM driver source had not changed.

The currently published runtime archives were uploaded on September 22, 2026, from commit 96c08f111b7ccf3d048a876c23e724014babb585 by workflow run #35667210266.

The VM driver and its embedded runtime are shipped in OpenShell releases. This issue concerns versioning the separate runtime archives consumed as build inputs.

Automatically refreshing hashes against the existing moving URLs would reduce manual work but would still invalidate existing checkouts whenever those archives are replaced. Immutable artifact references address that underlying problem.

Definition of Done

• Runtime builds selected by Nix use immutable URLs whose artifacts are retained and are not replaced by later publications.
• Successful publication automatically proposes a PR updating the runtime reference and hashes for all supported platforms together.
• CI verifies that the proposed artifacts match their hashes and that the runtime derivations build.
• Publishing a subsequent runtime does not invalidate the runtime references used by existing checkouts.
• The runtime update process is documented, including recovery when publication succeeds but the update PR fails.