Enforce tag immutability and provenance for published Bicep extension artifacts

TL;DR: Nothing prevents an already-published Bicep extension package from being quietly replaced, so users have no way to confirm that what they downloaded is what we released.

Engineering Improvement

Area for Improvement

Supply-chain integrity for the published Radius and AWS Bicep extension artifacts — registry configuration and a CI guard against republishing an existing version tag.

Observed behavior

Patch releases overwrite the <major>.<minor> extension tag in place (see #12959 for the mechanism). Nothing at the registry or pipeline level prevents a published tag from being replaced, and nothing records that it was.

Consequences:

• No immutable anchor for provenance. An accidental or malicious republish silently changes what every consumer of that tag compiles against, with no signal to users and no audit trail.
• Attestation is undermined. Signing or attesting an artifact is of limited value when the tag consumers reference can be repointed afterwards.
• Mirrors diverge. Mirrored and air-gapped registries differ in whether they re-sync moving tags, so downstream copies can silently disagree about what 0.60 contains.

Internal precedent points the other way: this repository already pins every GitHub Action to a commit SHA (e.g. actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 in .github/workflows/release.yaml), i.e. the project has already rejected mutable tags for its own supply chain while continuing to ship them to users.

Desired behavior

Version tags for published Bicep extensions are immutable and enforced as such by the registry, so that a republish attempt fails loudly instead of silently succeeding. Any tag that remains intentionally mutable (such as a floating channel alias) is explicitly enumerated rather than mutable by default.

Proposed Fix

1. Enable tag immutability / lock for published version tags on the extension repositories. Both ACR and GHCR support this.
2. Add a CI guard in the publish path that fails if the target version tag already exists, rather than overwriting it.
3. Explicitly allow-list any intentionally mutable alias tags, so mutability is opt-in and visible.
4. Document the guarantee alongside the versioning policy.

Scope note: this issue covers enforcement, not the policy itself. Which tags are immutable and which remain floating is decided in #12959, and this work should be sequenced after that decision. The enforcement mechanism is needed under either outcome — only the allow-list contents differ.

rad Version

N/A — release/supply-chain infrastructure analysis of main @ a0654b164.

Additional context

Related: #12937 (migrating the Radius and AWS Bicep extensions from ACR to GHCR). That migration is the natural point to land registry-side enforcement, since the immutability settings have to be configured on the new repositories anyway. Tracking it separately so the requirement is not lost when the migration issue closes.

Sequencing

• Blocked by: #12959. Enforcement is needed under either outcome, but the allow-list of intentionally mutable tags depends on the policy chosen there.
• Coordinate with: #12937 (ACR to GHCR migration). Immutability settings must be configured on the destination repositories as part of that move, so landing these together is likely cheaper than retrofitting.

Start with .github/workflows/release.yaml and trace the publish path for the Radius and AWS Bicep extensions. Review the policy decision in #12959 and the ACR-to-GHCR migration in #12937; done means version tags cannot be republished, intentional aliases are allow-listed, and the guarantee is documented.