Fix release tag lifecycle

[YunchuWang]

Summary

What changed?

• Removed all pre-merge Git tag creation and force-push behavior from Prepare Release.
• Kept package-scoped tag computation for branch naming, changelog baselines, summaries, and post-merge guidance.
• Added fail-safe instructions to tag the verified merged main commit without force, and required the official build to use that exact commit.
• Added an all-tags Azure Pipelines trigger to eng/ci/code-mirror.yml while preserving the existing main trigger, so each newly-created post-merge package tag uses the shared mirror template's dedicated tag path immediately.
• Added an operator gate requiring the tag-specific mirror run to resolve the internal tag to the exact merged commit and re-lock it before official build/release proceeds.

Why is this change needed?

• Prepare Release could move a GitHub release tag across reruns before the release PR merged, while the ADO mirror correctly refused to overwrite its existing tag. Release tags must be immutable and created only after merge.
• Without a tag trigger, the shared template's safe tag path is unreachable: a new release tag waits for a later main push, whose normal branch mirror path pushes --tags and can fail on an existing mismatched destination tag.
• After this PR merges, the existing Azure Managed mismatch can be reconciled by re-emitting the canonical GitHub tag through the tag-triggered pipeline path.

Issues / work items

• Resolves #
• Related #

---

Project checklist

• Release notes are not required for the next release
  • Otherwise: Notes added to CHANGELOG.md
• Backport is not required
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• All required tests have been added/updated (unit tests, E2E tests)
• Breaking change? No
  • If yes:
    • Impact: N/A
    • Migration guidance: N/A

---

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

• No
• Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
• Yes, an AI agent generated most of this PR

If AI was used:

• Tool(s): GitHub Copilot
• AI-assisted areas/files: .github/workflows/prepare-release.yaml, eng/ci/code-mirror.yml, doc/release_process.md
• What you changed after AI output: N/A; the generated diff was reviewed and validated directly.

AI verification (required if AI was used):

• I understand the code and can explain it
• I verified referenced APIs/types exist and are correct
• I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
• I reviewed concurrency/async behavior
• I checked for unintended breaking or behavior changes

---

Testing

Automated tests

• Result: Passed — both workflow YAML files parse; Azure trigger assertions preserve main and include all tags; rendered Summary shell syntax/content checks enforce the exact mirrored-commit and re-lock gate; existing/unused remote-tag guard cases pass; exact target-tag filtering uses fixed-string whole-line matching; forbidden tag-mutation assertions, git diff --check, and npm run lint pass.

Manual validation (only if runtime/behavior changed)

• Environment (OS, Node.js version, components): Windows; generated GitHub Actions summary rendered with Git Bash.
• Steps + observed results:
  1. Rendered the Summary step for Azure Managed 0.4.0 and confirmed it retains the Create PR link and identifies tag creation as the code-mirror trigger.
  2. Confirmed the prepare step pushes only the release branch without force and contains no tag mutation.
  3. Confirmed post-merge commands verify the merged commit/version and fail rather than overwrite an existing tag.
  4. Parsed eng/ci/code-mirror.yml and asserted its branch filter remains exactly main while its tag filter includes *.
  5. Confirmed the operator flow blocks official build/release until the internal tag resolves to the same MERGED_COMMIT and is locked.
• Evidence (optional): N/A

---

Notes for reviewers

• eng/ci/code-mirror.yml extends ci/code-mirror.yml@eng. For tag refs, that shared engineering template dispatches to ci/internal/code-mirror-tag.yml, which compares the destination tag, deletes the stale ADO tag with the mirror identity when needed, pushes the canonical GitHub tag, and re-locks it. The new tag trigger activates that existing reconciliation path; it does not mutate the canonical GitHub tag.
• After this PR merges, reconcile the live mismatch by re-emitting/recreating the already-canonical GitHub azuremanaged-v0.4.0 ref at d447907899830e47b9af0eb3994e01e0a5d69beb. That event should trigger the shared compare/delete/push/re-lock path under the mirror service identity. No separate ADO privilege intervention is expected if the shared template behaves as specified.

[Copilot]

Pull request overview

This PR updates the release preparation workflow and documentation to enforce an immutable release-tag lifecycle: tags are no longer created or force-moved pre-merge, and maintainers are guided to create the package-scoped tag only after the release PR is merged, pointing at the exact merged main commit.

Changes:

• Removed pre-merge tag creation and force-push behavior from Prepare Release; the workflow now only creates/pushes the release branch.
• Added post-merge, non-force tagging instructions that verify the merged commit and package version before creating the tag.
• Tightened publishing guidance to require the official build to use the exact tagged merged commit (not a later main commit).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/prepare-release.yaml	Stops creating/moving tags during preparation; updates summary output with safe post-merge tagging guidance.
doc/release_process.md	Documents post-merge tagging and aligns publishing steps with immutable tag + exact-commit build requirements.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.github/workflows/prepare-release.yaml:162

• grep -v "^${TARGET_TAG}$" treats ${TARGET_TAG} as a regex, so tag characters like . or + can match other tags and accidentally filter the wrong baseline. Use fixed-string + whole-line matching when excluding the target tag from the tag list.

          LATEST_TAG=$(git -c versionsort.suffix=- tag -l "${TAG_PREFIX}*" --sort=-v:refname | \
            grep -v "^${TARGET_TAG}$" | head -n 1)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.github/workflows/prepare-release.yaml:162

• The exclusion filter for the target tag uses a regex (grep -v "^${TARGET_TAG}$"). Because tag names contain . (and potentially other regex metacharacters), this can exclude the wrong tag(s) and produce an incorrect LATEST_TAG baseline for the changelog. Use a fixed-string, full-line match instead.

            grep -v "^${TARGET_TAG}$" | head -n 1)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.