fix: stop gating sign/release jobs and package version on github.ref for release events

[adrianhall]

Closes #495

Summary

The last two releases (10.1.0 and 10.1.1) failed to publish signed NuGet packages because github.ref/$env:GITHUB_REF was empty on the release: published event — confirmed byte-for-byte in the raw logs of runs 28783150142 and 27936434216:

GitHub Reference = 
BUILD_VERSION=10.0.0-build.54

This had two effects in both build-library.yml and build-template.yml:

1. The sign/release jobs' if: conditions string-matched against github.ref, so they silently skipped instead of failing.
2. GetBuildVersion.psm1 fell back to the main-branch build-number path, producing a bogus version (10.0.0-build.54 instead of the actual release tag).

Changes

In both build-library.yml and build-template.yml:

1. Gate sign/release on github.event_name instead of github.ref string matching. The release event no longer depends on ref resolution at all. Existing behavior for push-to-main (signs but doesn't release) and workflow_dispatch manual recovery (signs + releases against a dispatched ref) is preserved exactly:

   sign:
     if: >-
       ${{ github.event_name == 'release' ||
           (github.event_name == 'push' && github.ref == 'refs/heads/main') ||
           (github.event_name == 'workflow_dispatch' && (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/'))) }}
   release:
     if: >-
       ${{ github.event_name == 'release' ||
           (github.event_name == 'workflow_dispatch' && startsWith(github.ref, 'refs/tags/')) }}

2. Pass github.event.release.tag_name explicitly into the version step for release events, instead of relying on $env:GITHUB_REF, so a blank ref can't silently produce a wrong package version even if the gating logic above weren't fixed. tools/GetBuildVersion.psm1 itself is unchanged — the corrected version string is computed at the call site.

Scope notes (from discussion on #495)

• Recommendation 3 from the issue (a guard step in release that hard-fails on github.ref_name != github.event.release.tag_name) is deferred, tracked in Add fail-loudly guard to release job once github.ref-on-release-event behavior is confirmed resolved #496. Since github.ref/ref_name is empty on every observed release event so far, a literal hard-fail guard risks permanently failing every future release — even after this fix — until it's confirmed whether that emptiness persists (e.g. via a test release like 10.1.2) or was transient.
• Recommendations 4 (scheduled NuGet-vs-git-tag drift detector) and 5 (file a GitHub Support ticket) are explicitly optional in the issue and are out of scope for this PR.

Tests and checks run

• No src//tests/ changed, so dotnet build/dotnet test were not run — this is a CI-workflow-only change (same as the precedent set in build: enable NuGet trusted publishing for release workflows #494).
• ruby -ryaml parse of both modified files — valid YAML.
• actionlint (installed locally via brew install actionlint) run against both files — no new findings introduced. The only reported issues are pre-existing shellcheck info-level SC2086 warnings on lines this PR does not touch (confirmed identical, pre-existing on main before this change).
• Manually traced all four trigger paths (push-to-main, pull_request, release: published, workflow_dispatch against both a tag ref and main) against the new sign/release conditions to confirm behavior is unchanged for push/PR/workflow_dispatch and now correctly non-skipping for release events regardless of github.ref.

Skipped verification

• End-to-end verification of an actual signed, published release can only happen on a real tagged release: published run (the maintainer's comment on release event triggers with an empty github.ref, silently skipping sign/release jobs (broke 10.1.0 and 10.1.1 publishing) #495 mentions testing this via a 10.1.2 release).

Follow-up issues discovered

• Add fail-loudly guard to release job once github.ref-on-release-event behavior is confirmed resolved #496: revisit adding the fail-loudly guard to the release job once it's confirmed whether github.ref/github.ref_name reliably resolves on release events again.