Prevent stale release artifacts

[potpiemuncher]

Summary

• verify that the Linux amd64 release executable reports the pushed tag before creating a release
• create the GitHub draft release before publishing client packages to external registries
• skip NuGet setup, login, and publication when NUGET_USER is not configured
• tighten the moved build-info script so it passes ShellCheck

Root cause

The v0.0.5 tag workflow built the correct artifacts, but the create-release
job attempted all external package publication first. The job stopped at
NuGet/login@v1.2.0 because NUGET_USER was not configured, so the GitHub
release step never ran.

The subsequently published Windows release asset reports
v0.0.3-18-g02fffe6, while the Windows artifact retained by the failed tag run
reports v0.0.5 (FileVersion 0.0.5.0). Preserving the verified GitHub draft
before optional registry work prevents the correct binaries from being stranded
again, while registry failures remain visible in the workflow result.

Failed run: https://github.com/hbashton/VIIPER/actions/runs/30057594001

Impact

Release artifacts are now checked against the tag and attached to a draft
GitHub release before external registries can fail. Repositories that do not
publish the C# package can omit NUGET_USER without blocking the other release
work.

Validation

• actionlint 1.7.7 in Docker: passed
• go test ./... in golang:1.26-bookworm: passed
• replayed the new version guard against the retained v0.0.5 Linux amd64
  artifact: accepted v0.0.5
• replayed the same guard with expected version v9.9.9: rejected the artifact
  with a nonzero exit