ci(nuget): add NuGet release workflow with Trusted Publishing (OIDC)

[suchintan]

What

Adds the .NET release workflow to this repository — the sibling of release-npm.yml / release-pypi.yml, which also execute here — using NuGet Trusted Publishing (OIDC) from day one: the publish job (public-repo + v* tag + non-dry-run only, nuget environment) exchanges its Actions identity for a short-lived nuget.org key via SHA-pinned NuGet/login; no long-lived registry secret exists.

Requires (owner-side, already in motion): the nuget.org Trusted Publishing policy (owner Skyvern-AI, repo rustwright, workflow release-nuget.yml, environment nuget) and the NUGET_USER Actions variable naming the nuget.org account.

Companion PR on the development repository keeps the two copies identical.

🤖 Generated with Claude Code

[claude]

Summary

Clean, CI-only addition that mirrors the existing release-npm.yml/release-pypi.yml structure closely, uses OIDC Trusted Publishing (no long-lived NuGet secret), scopes id-token: write to only the publish job, and correctly guards publish behind github.repository == 'Skyvern-AI/rustwright'. No Rust/Python/Node runtime code is touched, so most FFI/CDP-specific review criteria don't apply here — feedback is limited to workflow-design nits.

🔴 Critical Issues (0)

None found.

🟡 Suggestions (2)

• Version validation gap for rustwright-capi: the metadata job's version-consistency check covers pyproject.toml, root Cargo.toml, node/Cargo.toml, node/package.json, the csproj, and the corresponding Cargo.lock entries for rustwright-core/rustwright-node — but not capi/Cargo.toml (currently 0.1.0-alpha.4, already diverged from the 0.1.1 used everywhere else) or the rustwright-capi entry in Cargo.lock. This is the first release workflow that actually builds and ships the capi crate as an artifact, so an unnoticed version drift there wouldn't be caught. Worth confirming this is intentional (capi versioned independently, publish = false) rather than an oversight, and if so maybe a one-line comment saying why it's excluded.
• Prerelease gate runs too late: "Require a prerelease version" (rejecting tags without a - suffix) only runs in the final publish job, after 5 native builds + packaging have already completed. Since it only depends on the tag name, it could move into the metadata job to fail fast — as-is, every stable-looking tag push (e.g. today's v0.1.1) will burn a full native-build matrix before failing at the last step.

📝 Minor / Style (1)

• Cross-compile approach diverges from the sibling workflow: Linux targets here use a hand-rolled zig cc linker wrapper (CARGO_TARGET_*_LINKER/CC_*), whereas release-npm.yml cross-compiles via cargo-zigbuild (taiki-e/install-action + --zig flags). Plausibly fine since capi is a much simpler C-ABI cdylib with no proc-macro/build-script complexity that zigbuild's extra patching exists to solve, but flagging in case it was meant to reuse the existing mechanism rather than introduce a second one to maintain.