Automate NuGet and GitHub releases

[eamsden]

What changed?

• Start release publication automatically after a successful NuGet Package run on main or a release branch when the SDK version changed.
• Reuse the exact package artifact and source commit from that run instead of rebuilding packages during publication.
• Keep the existing integration-gallery publish and smoke test followed by nuget.org publish and smoke test.
• Wait for all seven published package IDs and verify both each runtime package and symbol package against the originating workflow artifact.
• Create the matching Git tag and GitHub release only after production packages pass their smoke test.
• Build release notes from the curated CHANGELOG.md Unreleased section and GitHub-generated contributor/change notes.
• Isolate concurrency by immutable release candidate so one pending version cannot displace another, while making retries accept only matching published artifacts and GitHub state.
• Use GitHub's server-side legacy latest-release selection so concurrent or delayed stable releases cannot leave an older version marked latest.

Why?

The current release workflow must be dispatched manually and stops after NuGet publication. This makes the version-bump merge the single release trigger and completes both NuGet and GitHub publication from the same immutable package build.

This is intentionally much smaller than the Temporal-backed Java release automation in temporalio/sdk-java#2995. NuGet Trusted Publishing, immutable Actions artifacts, and the existing integration/production smoke gates provide the required sequencing and retry behavior without another orchestration runtime.

Verification

• Full repository CI matrix, feature tests, security scan, changelog check, and dependency submission are green.
• Actionlint, ShellCheck, Bash syntax validation, and git diff --check pass.
• Production and integration symbol CDN endpoints were checked against an existing Temporalio release.
• No workflow, package publication, tag, or GitHub release was dispatched while developing this change.

The release scripts intentionally do not have a mocked test harness or a CI-for-CI job. This is an internal SDK-team release utility; the chosen maintenance bar is readable production scripts, static validation, and the live repository CI/release gates rather than maintaining mocks of GitHub and NuGet behavior.