.NET: Update versions for release

[westey-m]

Motivation and Context

Description

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[Copilot]

Pull request overview

Bumps the .NET NuGet package versioning metadata in preparation for the next release, using the centralized nuget-package.props properties that drive package version and tagging.

Changes:

• Update VersionPrefix from 1.2.0 to 1.3.0
• Update DateSuffix from 260421 to 260423
• Update GitTag from 1.2.0 to 1.3.0

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 95%

✓ Correctness

Straightforward version bump from 1.2.0 to 1.3.0 with DateSuffix updated to today's date (260423). All three changes (VersionPrefix, DateSuffix, GitTag) are internally consistent: VersionPrefix and GitTag both move to 1.3.0, and the PackageVersion conditions all derive from $(VersionPrefix) so they will correctly pick up the new version. No correctness issues found.

✓ Security Reliability

This is a straightforward version bump from 1.2.0 to 1.3.0 in the central NuGet package properties file, with the DateSuffix updated from 260421 to 260423 (matching today's date of April 23, 2026). The VersionPrefix and GitTag are updated consistently. No security or reliability concerns.

✓ Test Coverage

This is a straightforward version bump from 1.2.0 to 1.3.0 in the NuGet package properties file, along with an updated date suffix (260421 → 260423) and matching GitTag update. This is a build/packaging configuration change with no behavioral code modifications, so there is no new or changed behavior that would require test coverage. No issues found.

✗ Design Approach

The version bump is mostly self-consistent, but it misses the release-contract update that keeps package validation meaningful for GA packages. Advancing the shared package version to 1.3.0 while leaving the validation baseline at 1.0.0 means released packages will continue comparing against a much older baseline instead of the latest published stable version, which can hide compatibility regressions introduced after 1.0.0.

Suggestions

• Treat VersionPrefix/GitTag and PackageValidationBaselineVersion as one unit of release bookkeeping so GA validation always compares against the immediately previous stable release.

---

Automated review by westey-m's agents