chore(release): evaluate promoting qualified pre-release artifacts instead of rebuilding for stable

[purp]

Description

Decide whether stable releases should publish the exact bytes of the qualified pre-release (promotion) or rebuild the qualified commit with the stable version (rebuild), and what it would take to make promotion possible.

The initial RFC 0014 qualification work (#3559) will rebuild, because every pre-release artifact embeds its pre-release version today. Rebuilding has a cost we want to remove: each stable build is another execution of the full toolchain and dependency graph, and so another opportunity for a supply-chain compromise to enter an artifact that qualification never exercised. Promotion would make the qualified bytes and the published bytes identical.

Context

RFC 0014 does not settle this. Qualification must exercise the pre-release artifacts "rather than a substitute source build" (rfc/0014-release-stability/README.md). Stable publication is described only as "Publish stable artifacts" followed by undefined "Final artifact checks" before the tag is created.

Entanglement with "no version in source." The RFC's version-selection supplement makes Git tags the version source of truth: "release versions are never committed to source." The build therefore injects the version from the tag at build time, and every artifact carries it. For v0.1.0-pre.7:

Artifact	Embedded version	Where it's injected
Rust binaries (--version)	0.1.0-pre.7	build-rust-binary rewrites version = "0.0.0" in Cargo.toml (tasks/scripts/release.py, _versions_from_prerelease)
Default supervisor image tag compiled into binaries	0.1.0-pre.7	release-tag.yml passes supervisor-image-tag: semver
Gateway, sandbox, supervisor images	Same as binaries	build-docker-image copies the prebuilt binaries in
Deb	0.1.0~pre.7-1	release.py
RPM	0.1.0-0.pre.7	release.py
Python wheel	0.1.0rc7	SETUPTOOLS_SCM_PRETEND_VERSION
Snap	0.1.0-pre.7	release.py
Helm chart / app version	0.1.0-pre.7	release-tag.yml chart-version / app-version

Because the stable tag doesn't exist until the pre-release has qualified, the stable version can't be in any artifact built before that point. Republishing pre-release bytes as stable would ship binaries reporting 0.1.0-pre.7 and defaulting to supervisor:0.1.0-pre.7.

Promotion therefore requires separating "what was compiled" from "what version it's called." Directions to evaluate, not an exhaustive list:

• Version-neutral compiled artifacts, with the version stamped at packaging time (package metadata, image tags, chart version) and discovered at runtime from that metadata.
• Keeping the version out of compiled code while still identifying the build, e.g. by source commit or digest, and mapping that to a release version externally.
• Reproducible builds, so a rebuild can be verified bit-for-bit against the qualified artifact (reduces, but doesn't remove, the rebuild's trust surface).

Related: #3559 (RFC 0014 security qualification).

Definition of Done

• Written comparison of promotion vs. rebuild covering supply-chain exposure, what qualification actually vouches for, and operational cost.
• Inventory of every place a version is compiled into or embedded in a release artifact, and what depends on each (e.g., --version, default supervisor image tag, package-manager upgrade ordering).
• Assessment of whether the "no version in source" decision can coexist with promotion, and what would have to change if not.
• Recommendation, with follow-up issues if promotion is pursued.

[purp]

Requirement for the promotion path: qualification suites added after a pre-release was qualified must still reach its artifacts before they're promoted.

With rebuild, stable artifacts are new and run the full implemented qualification profile, so newly added suites are covered automatically. With promotion, the stable artifacts are the pre-release bytes, and their existing results stand. Promotion therefore needs to:

• Record, on every qualification result, the profile version it ran under.
• At promotion time, compare the candidate's results against the current profile.
• Run any suite the current profile implements but the candidate has no result for, against the candidate's stored artifacts, before deciding eligibility.

Without this, a critical test added between a pre-release's qualification and its promotion would never run against the shipped artifacts.