Publish immutable per-patch Bicep extension tags: rel_version is missing from the publisher dispatch payload #12962

TL;DR: Our release pipeline tells the package publisher only the 0.60 part of a version and never the .2, so publishing a Bicep extension package tagged with the exact patch version is currently impossible.

Engineering Improvement

Area for Improvement

Release pipeline — the build-and-push-bicep-types job in .github/workflows/build.yaml and its dispatch payload to azure-octo/radius-publisher.

Observed behavior

The publisher dispatch passes only the release channel, never the full release version:

- name: Repository Dispatch
  id: repository-dispatch
  uses: peter-evans/repository-dispatch@...
  with:
    repository: azure-octo/radius-publisher
    event-type: bicep-types
    client-payload: |-
      {
        "source_repository": "${{ github.repository }}",
        "source_ref": "${{ github.ref }}",
        "source_sha": "${{ github.sha }}",
        "rel_channel": "${{ env.REL_CHANNEL }}",
        "registry_target": "radius"
      }

.github/scripts/get_release_version.py computes both values for a full release tag v0.60.2 — REL_VERSION=0.60.2 and REL_CHANNEL=0.60 — but only rel_channel crosses the boundary.

The consequence is structural: the publisher cannot produce a radius:0.60.2 tag even if we decide it should. It never receives the patch version. Every patch release can only overwrite radius:0.60.

Desired behavior

The dispatch payload carries the full release version alongside the channel, so the publisher is capable of pushing an immutable per-patch tag (0.60.2) in addition to the moving channel tag (0.60), both pointing at the same manifest.

Proposed Fix

1. Add "rel_version": "${{ env.REL_VERSION }}" to the client-payload in build-and-push-bicep-types.
2. Update the corresponding publish-bicep-types.yml workflow in azure-octo/radius-publisher to push both tags.
3. Confirm behavior for prerelease tags, where REL_CHANNEL is already the full version (e.g. 0.61.0-rc1) — the two tags collapse to one and the publisher must handle that without failing.

This change is purely additive and enables no behavior change on its own — the channel tag keeps working exactly as it does today, and nothing consumes the new tag until follow-up work lands. It can ship independently and ahead of the policy decision.

rad Version

N/A — CI/release pipeline analysis of main @ a0654b164.

Additional context

Enabler for the tagging policy decided in #12959. That issue owns whether and how the new tag becomes the default pin; this one only makes it possible to publish.

Also unblocks a rollback path: today, reverting a Radius install from 0.60.2 to 0.60.0 does not revert types, because tag 0.60 still serves 0.60.2 content and no 0.60.1 extension tag exists to pin back to.

Sequencing

• Blocked by: nothing. Purely additive, no behavior change — ready to pick up now, ahead of the policy decision.
• Blocks: the exact-pin direction proposed in Decide the Bicep extension tagging policy: stop overwriting release channel tags #12959 cannot be implemented until this lands, and it makes the structural fix for Bicep extension type fixes shipped in patch releases never reach users with a warm ~/.bicep cache #12961 possible.
• Related: Decide the Bicep extension tagging policy: stop overwriting release channel tags #12959 (owns whether the new tag becomes the default pin).