ci(release): promote qualified prereleases to stable

[SDAChess]

Summary

Dispatch Release from the intended branch with a stable version to select its latest passing prerelease, verify its recorded qualification evidence, and create the stable tag at that exact commit. Rebuild and publish stable artifacts without repeating qualification, while keeping support releases from replacing newer shared latest channels.

Related Issue

Closes #4609.

Builds on #4420, which is merged. Related: #3559 and #3632. Artifacts are rebuilt because their versions are compiled in.

Changes

• Replace stable tag-push publication with manual promotion, scoped to the requested version and selected branch history. Verify the qualification profile, source commit, run, artifact attempt, and retained evidence from successful reruns. Existing stable tags never move.
• Read candidates highest-first, paginate runs lazily, cache artifact listings, and stop after verifying a candidate. Unsuccessful searches can still traverse historical runs.
• Save stable images as multi-platform OCI archives during the build, then publish those archives under version tags with preserved digests and attestations. Verify published SBOMs before updating latest; preserve the prerelease's commit-SHA images.
• Run shared version calculation, Python wheel building, and TypeScript publishing with Nix and direct uv/npm commands, without the CI image or mise.
• Preserve GHCR latest, GitHub's latest release, npm latest, and snap latest/stable for older support versions. Support npm packages use release-X.Y; snap files stay in GitHub Releases. Docs already prevent latest from moving backward.
• Update release guidance, workflow references, and baseline metrics.

Testing

• Ruff lint and formatting, Actionlint with ShellCheck, offline Zizmor, and git diff --check pass. Exclude only Actionlint's unsupported queue: max diagnostic; the existing branch-docs credential-persistence warning remains unchanged.
• Disposable candidate-selection checks cover numeric ordering, early stopping, pagination, branch and SHA isolation, expired evidence, retained evidence after reruns, source mismatch rejection, and stable-tag immutability.
• Local OCI archive copying preserves both architectures, attestations, and every digest.
• Isolated Nix runs calculate release versions, generate Python protobufs, build and verify the versioned wheel, install and build the TypeScript SDK, and dry-run npm publication under latest and release-0.4.
• Rebased onto current main; both original patches were unchanged by the rebase before adding the Nix update.
• Earlier focused verification also covered image aliases, metrics attribution, guidance consistency, and a real qualification summary retained after a successful rerun.
• No release suites or workflows were dispatched; live GitHub tag creation and end-to-end publication remain unverified. No repository tests were added.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Relevant documentation and contributor guidance updated

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-4611.docs.buildwithfern.com/openshell

[matthewgrossman]

Nice design overall. The evidence check is strict, existing stable tags never move, the build re-checks the source commit, and successful reruns keep earlier evidence. Together these make a mis-tag hard. Thanks for also picking up the two follow-ups from #4420. Inline comments cover the npm bug and the rebuild tradeoff; two notes here are about lines outside the diff:

• Shared image tag. release-build.yml still pushes stable images to gateway|sandbox|supervisor:<source_sha>. That is the same tag the qualified prerelease used and that qualification scanned and tested. After promotion, :<sha> points to the stable rebuild, not the evaluated image. The :X.Y.Z-pre.N tags still point to the qualified images, so nothing breaks. Anyone following the evidence by commit, or rerunning integration with source-sha, gets different bits. If a Pre-release or Release Dev run for the same commit overlapped, :X.Y.Z could even be created from a prerelease image. That risk predates this PR. Low priority, but a distinct tag for the stable build, such as <sha>-stable, would avoid it.
• Live run. Nothing was dispatched for this or #4420. A throwaway-tag run on a fork before the first real promotion would cover tag creation with the workflow token, the artifact zip download, and cross-workflow permissions.