Use NuGet trusted publishing

[HavenDV]

Migrate the release job from the expired long-lived NuGet API key to GitHub Actions trusted publishing.

• grant only contents read and OIDC token issuance
• exchange the GitHub OIDC token via NuGet/login
• keep package publication scoped by the NuGet.org policy

Validation: actionlint .github/workflows/dotnet.yml

[claude]

Reviewed the workflow change. Small, focused diff that swaps a long-lived NuGet API key for OIDC-based trusted publishing — good move from a security standpoint (no more static secret to leak/rotate).

Looks good:

• Job-level permissions: { contents: read, id-token: write } follows least privilege — only grants what's needed for checkout + OIDC token issuance, nothing broader (no contents: write, packages: write, etc.).
• No leftover references to the old secrets.NUGET_KEY anywhere else in the workflow — the cutover is clean.
• Consistent with existing action-pinning style in the file (@v6, @v5, etc. — none of the existing actions are SHA-pinned either).

Worth a look / minor suggestions:

1. Action version pinning for a credential-issuing step: NuGet/login@v1 is pinned to a mutable major-version tag rather than a commit SHA. Since this step now has id-token: write and produces a short-lived NuGet API key, consider pinning to a full commit SHA (with a # vX.Y.Z comment) for supply-chain hardening — a compromised or re-tagged v1 could otherwise exfiltrate the OIDC-derived credential. This is optional/consistent with the rest of the file's convention, so take it as a "nice to have" rather than a blocker.
2. Publish runs on every push to master, not just tags: this predates the PR (the Publish step already had no if gate), so it's not introduced here, but now that the credential exchange (NuGet/login) also runs on every master push, it's worth double-checking that's intentional — trusted publishing usually still expects --skip-duplicate to make repeated non-release pushes a no-op, which is already in place, so this is likely fine as-is.
3. Double check the trusted publishing setup on nuget.org side: trusted publisher policies are tied to the exact repo + workflow filename (and optionally a GitHub Environment). Since this workflow doesn't declare an environment:, make sure the nuget.org trusted publisher policy for this package doesn't require one, otherwise the OIDC exchange will fail at publish time (easy to verify once, but hard to unit test in CI).

No functional/test-coverage concerns beyond the CI file itself — this is pure pipeline plumbing. Nice, minimal change overall.