chore: move release publishing to Azure pipelines

[Jane Chu (janechu)]

Pull Request

📖 Description

Moves FAST release publishing from the nightly GitHub Actions workflow and legacy
root-level Azure definition to two release pipelines under .ado/pipelines/, keeping
release credentials and registry publication in Azure:

• FAST - CD Build runs on pushes to main, selects every publishable workspace
  whose ${name}_v${version} tag is missing, and preserves that exact comma-separated
  selection through npm and paired Rust crate packing.
• The build produces a strict release manifest containing source provenance, package
  metadata, output prefixes, exact asset filenames, and SHA-256 hashes. Packing and
  validation reject malformed selections, version drift, partial batches, duplicate
  output contracts, and missing, modified, nested, or unexpected files.
• FAST - CD validates the selected build and artifacts, creates annotated release
  tags at the validated commit, publishes npm and crates.io assets, records
  deployed/<release-tag> markers, and then creates package-specific GitHub Releases.
• Git tag operations use targeted remote queries and isolated refs with race-safe,
  same-commit idempotency. GitHub Release retries skip only complete releases and fail
  explicitly when an existing release is malformed or missing manifest assets.
• Adds queue-time validation mode, shallow tag-free checkouts, run-number package
  counts, strict npm pack --json validation, and regression coverage for pipeline
  ordering, output-variable wiring, release-check wiring, package/task coverage, and
  structured Azure errors.
• Removes the superseded GitHub release workflow and scripts, and updates contributor,
  workflow, testing, and Azure pipeline documentation for the new release process.

👩‍💻 Reviewer Notes

• The Azure definitions must be registered with the exact names FAST - CD Build
  and FAST - CD, with the pipeline resource and service connections configured as
  documented in .ado/pipelines/README.md.
• Release tags are intentionally created before registry publication. If registry
  publication fails, the release tag remains without a deployment marker; after
  diagnosing the failure, a maintainer must delete the affected release tag before
  rebuilding and retrying that version.
• End-to-end dry runs can use validationMode: true in both pipelines. Validation mode
  builds and verifies already-tagged releases without creating tags, publishing
  packages, adding deployment markers, or creating GitHub Releases.

📑 Test Plan

• npm run build
• npm run test
• npm run test:scripts — 43 tests pass.
• npm run biome:check
• npm run checkchange
• Parsed the new and modified Azure pipeline YAML files successfully.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

Agents

• I have linked to an existing issue in this project that this change addresses
• I have read the skills
• I have read the DESIGN.md file(s) in packages relevant to my changes
• I have updated the DESIGN.md file(s) in packages relevant to my changes

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Jane Chu (janechu)]

Requesting changes for release-path consistency and retry safety.

[Jane Chu (janechu)]

A few remaining release-validation guardrails should be closed before landing.

[Jane Chu (janechu)]

One remaining release-pipeline consistency gap should be addressed.