Implement .NET UpdatePackageVersion

[m-redding]

Closes #13832

Architecture: Version Update Flow

Why UpdateReleaseDate replaces the latest entry instead of doing an exact version lookup

In azure-sdk-for-net changelogs always have the latest entry at the top in this format by default:

   ## 12.28.0-beta.2 (Unreleased)
   
   ### Features Added
   - Feature A
   - Feature B
   
   ### Breaking Changes
   
   ### Bugs Fixed
   
   ### Other Changes

The whole point of a version update tool is to handle the transition from one version to another — e.g., taking the default version 12.28.0-beta.2 to 12.28.0 for a GA release, or bumping 12.28.0-beta.2 to 12.28.0-beta.3. If the tool required the changelog to already have an entry matching the target version, the user would need to manually edit the changelog first.

The new behavior matches how Prepare-Release.ps1 works: it always sets $replaceLatestEntryTitle = $true, which takes the latest entry, replaces its title (version + release date), and preserves the content underneath. So ## 12.28.0-beta.2 (Unreleased) becomes ## 12.28.0 (2025-06-15).

Why we removed the Update-PkgVersion.ps1 dependency

The original implementation shelled out to the repo's Update-PkgVersion.ps1 PowerShell script. This had a fundamental problem: the script declares [Boolean]$ReplaceLatestEntryTitle, and PowerShell's -File mode cannot convert any string argument to [Boolean] — not $true, not 1, nothing. Using -Command mode would work around this but is injection-prone and explicitly discouraged in this repo. Since the C# base class already has all the functionality the script provides (changelog updates via ChangelogHelper and version file updates via UpdatePackageVersionInFilesAsync), the script dependency was unnecessary complexity.

Why stable (GA) releases require explicit --release-type stable

When neither --version nor --release-type is provided, the tool defaults releaseType to "beta". If a package's current version happens to be stable (e.g., 1.0.0), the version would be inferred as 1.0.0 and the tool would proceed with a GA release — which is a high-impact action that shouldn't happen by accident. The validation now requires --release-type stable to confirm intent for any stable version, whether explicitly passed or inferred from the package.

[Copilot]

Pull request overview

Adds .NET package version update support to azsdk-cli by implementing .NET-specific version file updates and aligning some .NET checks with the shared ParsePackagePathAsync parsing flow.

Changes:

• Add DotnetLanguageService version update implementation with a primary PowerShell script path (Update-PkgVersion.ps1) and a .csproj <Version> fallback.
• Update .NET language checks to derive service/package names via IPackageInfoHelper.ParsePackagePathAsync (and MSBuild metadata where available).
• Add new unit tests covering script vs fallback behavior and edge cases.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/Languages/DotnetLanguageService.VersionUpdate.cs	Implements .NET version update logic (script + fallback) and release-type validation.
tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/Languages/DotNetLanguageService.Checks.cs	Updates .NET checks to use repo-root/relative-path parsing and MSBuild package name.
tools/azsdk-cli/Azure.Sdk.Tools.Cli.Tests/Services/Languages/DotnetLanguageServiceVersionUpdateTests.cs	Adds coverage for script success/failure, fallback behavior, and version/tag edge cases.
tools/azsdk-cli/Azure.Sdk.Tools.Cli.Tests/Services/Languages/DotNetLanguageSpecificChecksTests.cs	Adjusts test setup to mock ParsePackagePathAsync for updated checks behavior.

[Copilot]

Pull request overview

Adds .NET-specific version update support to azsdk-cli by teaching DotnetLanguageService how to update package versions via the .NET repo’s Update-PkgVersion.ps1 script, with a .csproj-edit fallback when the script isn’t available. It also refactors .NET check workflows to derive service/package identity via IPackageInfoHelper.ParsePackagePathAsync, and introduces a dedicated test suite for the new version-update behavior.

Changes:

• Implemented .NET version update flow by overriding DotnetLanguageService.UpdateVersionAsync and UpdatePackageVersionInFilesAsync with script-first + .csproj fallback logic.
• Updated .NET checks to compute serviceDirectory/packageName via ParsePackagePathAsync (and MSBuild metadata when available), removing ad-hoc path parsing.
• Added new unit tests covering script invocation, fallback behavior, and release-type/version edge cases.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/Languages/DotnetLanguageService.VersionUpdate.cs	New .NET version update implementation (script-first with direct .csproj fallback).
tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/Languages/DotNetLanguageService.Checks.cs	Refactors service/package derivation to use ParsePackagePathAsync; fixes AOT script arg construction.
tools/azsdk-cli/Azure.Sdk.Tools.Cli.Tests/Services/Languages/DotnetLanguageServiceVersionUpdateTests.cs	New tests validating script/fallback behavior and release-type validation.
tools/azsdk-cli/Azure.Sdk.Tools.Cli.Tests/Services/Languages/DotNetLanguageSpecificChecksTests.cs	Updates test setup to mock ParsePackagePathAsync consistently.