[FEATURE REQ] Validate official emitter dependency versions in C# emitter CI #63865

Library name

@azure-typespec/http-client-csharp and @azure-typespec/http-client-csharp-mgmt

Please describe the feature.

Add dependency-version validation to the existing CI pipelines for eng/packages/http-client-csharp and eng/packages/http-client-csharp-mgmt, so an accidental upgrade to a non-official emitter package from a regeneration preview fails before the PR can merge.

Background

PR #63822 — Update management branded C# generator and async paging compatibility upgraded the management emitter's @azure-typespec/http-client-csharp dependency from 1.0.0-alpha.20261009.2 to 1.0.0-alpha.20261013.3. At the time of this incident, the latest official Azure emitter version was 1.0.0-alpha.20261013.2. The newer version appears to have come from a regeneration-preview publication rather than an official publication from main.

The PR merged, and the existing validation caught the dependency mismatch only later, during the generator-upgrade PR workflow:

Regenerating emitter version dashboard...
Submit-AzureSdkForNetPr.ps1 : Error creating PR:
Management emitter dependency version '1.0.0-alpha.20261013.3' is newer than the approved version '1.0.0-alpha.20261013.2' in '/mnt/vss/_work/_temp/azure-sdk-for-net-20261014-174646/eng/azure-typespec-http-client-csharp-emitter-package.json'. Wait for the approved emitter package descriptor to be updated before advancing this dependency.

This leaves ordinary emitter PRs able to introduce an unintended preview dependency, with the failure surfacing in a subsequent, separate workflow.

Existing validation and integration points

• doc/GeneratorVersions/Emitter_Version_Dashboard.ps1 already checks the management emitter's Azure emitter dependency and Azure.Generator version against eng/azure-typespec-http-client-csharp-emitter-package.json. It supports -ValidateOnly, without regenerating the dashboard or querying the npm registry.
• eng/scripts/tests/Emitter-Version-Dashboard.tests.ps1 covers approved, older, and newer versions for that check.
• Both http-client-csharp/ci.yml and http-client-csharp-mgmt/ci.yml use eng/pipelines/templates/archetype-typespec-emitter.yml, providing an integration point for normal emitter PR validation.

Requested behavior

Decouple/reuse the existing check, or introduce a shared standalone validator, and invoke it from both emitter CI pipelines independently of generator-upgrade PR creation and dashboard generation.

Validate the upstream emitter dependencies referenced by the package manifests and resolved lockfiles:

• http-client-csharp: @typespec/http-client-csharp.
• http-client-csharp-mgmt: @azure-typespec/http-client-csharp and @typespec/http-client-csharp.

Reject packages published from PR/feature branches or regeneration previews rather than official main builds in the dependency's source repository. Use the approved package descriptors and/or trustworthy publication provenance as appropriate. A version being available on a package feed, or merely being numerically older than an approved version, is not by itself proof of an official main publication.

Official releases can themselves have alpha versions; this is a publication-origin check, not a blanket ban on prerelease versions. The approved version must be read dynamically rather than hard-coding the incident's 1.0.0-alpha.20261013.2.

Acceptance criteria

• Both emitter PR CI pipelines run this validation before merge, without requiring the generator-upgrade workflow.
• An unintended dependency such as @azure-typespec/http-client-csharp@1.0.0-alpha.20261013.3 in this incident is rejected, and approved official dependencies continue to pass.
• Older official main publications remain valid; preview/non-main publications do not pass solely because of their version ordering.
• Validation covers manifest references and actual lockfile resolutions, and relevant dependency, validator, and approval-descriptor changes trigger the check.
• Failures identify the consuming emitter, dependency, referenced/resolved version, and approval/provenance reason, with actionable guidance. Inability to establish approval/provenance is reported explicitly rather than silently passing.
• Automated coverage includes approved official versions, supported older official versions, preview/non-main versions, and manifest/lockfile mismatches.