fix(workflows): match brandedoutcast/publish-nuget's gating 1:1, verify remote tag state

[Foowy]

Summary

• Follow-up to fix(workflows): force-push the release tag on nuget publish #1406. Thanks @revam for flagging: force_push_tag: true does actually work (the force-push branch in action-create-tag's entrypoint never reads its own local-only tag_exists check — it always force-tags+pushes when force_push_tag is set), but it does so blindly, with no comparison against what the remote tag currently points to. Since this repo's checkout intentionally doesn't fetch tag history, there was no way to detect if a release tag ever ended up pointing at an unexpected commit (manual retag, a bug elsewhere) — this workflow would silently force it back to the new commit with no warning, masking a real problem instead of surfacing it.
• Adds a "Check remote tag state" step ahead of the existing rickstaa/action-create-tag step (kept in place, not replaced): queries the remote tag directly via git ls-remote (a lightweight network call — no history fetch) and only lets the tag step run when the remote either doesn't have the tag yet or already points at the exact commit being published. If it points anywhere else, the job fails loudly instead of letting the tag step overwrite it.
• git ls-remote origin "refs/tags/$TAG" "refs/tags/$TAG^{}" returns two lines for an annotated tag (the tag-object SHA and its peeled ^{} commit SHA) — tail -1 picks the commit SHA in both the annotated and lightweight cases. Verified this against upstream's actual Shoko.Abstractions-v6.0.0-alpha.77 tag.
• Also restores 1:1 parity with the archived brandedoutcast/publish-nuget action, which repo(workflows): replace archived publish-nuget action, resolve Node 20 deprecation #1401 didn't actually achieve: that action queried NuGet.org's own version index up front and skipped pack/push/tag entirely for an already-published version, so an unchanged-version day was a silent no-op. The composite action always ran pack/push/tag unconditionally and relied only on dotnet nuget push --skip-duplicate to no-op the package push, while the tag step still ran every single time regardless — that decoupling is the actual root cause of the whole Shoko.Abstractions-v6.0.0-alpha.77 tag conflict across repo(workflows): replace archived publish-nuget action, resolve Node 20 deprecation #1401/fix(workflows): don't fail nuget publish when release tag already exists #1405/fix(workflows): force-push the release tag on nuget publish #1406. Added a "Check if version is already published" step that queries https://api.nuget.org/v3-flatcontainer/{packageId}/index.json and gates Pack/Push/Tag on the version being genuinely new — matching the old action's behavior instead of approximating it.
• The git ls-remote tag check stays as a second line of defense on top of the NuGet.org gate — it still protects the tag from being clobbered even on an unexpected rerun.

Test plan

• Verified the git ls-remote resolution logic against three simulated cases on a local checkout that exactly replicates CI's shallow, tags-excluded actions/checkout@v7 default: a brand-new tag (creates+pushes, exit 0), an idempotent same-commit rerun (skips cleanly, exit 0), and a tag pointing at a different commit (fails loudly, remote tag confirmed unmoved)
• Verified the NuGet.org version-check logic against real data: an existing package+version (shoko.abstractions / 6.0.0-alpha.77, found), a nonexistent version (not found), and a nonexistent package (404, handled explicitly)
• Next "Build (Daily)" run on master completes the publish jobs successfully (idempotent re-publish case, unchanged version)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Foowy]

Superseded by 4f0e3c5 (revam's fix(workflows): fetch tags on checkout and don't error on existing publish tags, pushed directly to master).