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

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:

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.