ci: stop force-pushing exact release tags

[mldangelo]

Companion to promptfoo/promptfoo#9991, addressing finding 3 of promptfoo/promptfoo#9985: exact version tags (e.g. v0.1.8) were created with git tag -fa and pushed with --force alongside the floating v0/v0.1 aliases, so pinning to an exact patch tag was not immutable.

With this change:

• The exact version tag is created once and pushed without --force. If the tag already exists at a different commit (a same-version re-release), the job fails loudly instead of silently re-pointing the release — bump the version to release again.
• Re-runs of the job on the same release commit remain idempotent (existing tag at GITHUB_SHA is left as-is; the non-force push is a no-op).
• Only the floating major/minor aliases (v0, v0.1) continue to move, which is their documented purpose.
• Even if the local clone somehow lacks tags, the non-force push still fails safe: the remote rejects a non-fast-forward tag update.

Note this makes exact tags immutable by process, not cryptographically — a repo admin can still delete/re-push tags. Two settings-level follow-ups worth considering (not possible via PR):

1. Enable GitHub's immutable releases for this repo, which freezes a release's tag at publish time.
2. Add a tag ruleset protecting v* from deletion and non-fast-forward updates, scoped so the release workflow can still create tags and move only v0/v0.x aliases.

Verification: exact-tag creation/push logic exercised against the failure matrix (fresh release, re-run same commit, same-version re-release, raced remote) — see the inline comments.