scripts: harden tag-release.sh ref resolution

[ziggie1984]

Summary

Hardens ref resolution in scripts/tag-release.sh. The helper's behavior and
CLI surface are unchanged: it still verifies that HEAD matches the upstream
branch tip and tags HEAD, and --branch still selects the upstream branch to
verify against.

• fetch a fully qualified refs/heads/<branch> refspec
• peel FETCH_HEAD to a commit before comparing it against HEAD
• pass --no-tags
• reject an empty --branch= value instead of silently falling back to the
  current branch

Motivation

git fetch <remote> <name> resolves a tag named <name> ahead of a branch of
the same name. A tag shadowing a release branch would therefore leave
FETCH_HEAD on unrelated history. Fetching refs/heads/<name> removes the
ambiguity.

The refspec and the peel belong in the same change. Today the SHA comparison
happens to fail closed under such a collision, because git rev-parse FETCH_HEAD yields the annotated tag object and that can never equal a commit
id. Peeling on its own would convert that into a silent success on the tag's
target commit, so peeling is only safe once the refspec pins refs/heads.

--no-tags is hygiene rather than a fix. With an explicit refspec, tag
auto-following does not happen by default; it happens only when
remote.<name>.tagOpt=--tags is configured, in which case a verification step
that should be read-only silently mutates the local tag namespace. It cannot
affect any decision the script makes, since the duplicate-tag check is a
git ls-remote query against the remote.

Note that no such collision exists today — lnd release tags look like
v0.21.2-beta and would not shadow v0.21.x-branch. This closes the shape
rather than a live bug.

Note on the previous revision of this PR

An earlier version of this branch changed --branch to fetch and tag the
upstream branch tip directly, so that a release could be cut without checking
the branch out. That has been dropped.

The motivating problem was that scripts/tag-release.sh did not exist on
v0.20.x-branch, which has since been addressed by backporting the script.
Retargeting also gave up a property worth keeping: because the existing check
hard-fails on a HEAD/upstream mismatch rather than merely reporting it, both
designs guarantee equally that the signed commit is the upstream branch tip, but
only the original guarantees that the maintainer had that tree checked out when
signing it.

Validation

• bash -n scripts/tag-release.sh passes; no added line exceeds 80 characters

• --branch= and --branch with no value both exit 1 with usage

• live run against origin master with a deliberately mismatched tag:
  FETCH_HEAD resolved to branch 'master' rather than a tag, peeled to a
  commit object, local tag count unchanged (412), and no tag was created
  Exercised end to end on git 2.50.1 against a throwaway upstream carrying the
  collision this change is about: a branch v9.9.x-branch at commit Y
  (build/version.go = 9.9.1) and an annotated tag of the same name at an
  unrelated commit X (9.9.0).

• this branch, HEAD at Y: verification passes and targets Y, the branch tip,
  rather than X (the run then stops at gpg for want of a key in the sandbox,
  which is past every check)

• master's script, same situation: aborts, reporting an Upstream: SHA that
  is neither X nor Y but the annotated tag object, since that can never equal a
  commit id

• peel applied without the qualified refspec, HEAD at X: passes verification and
  would tag X rather than the branch tip, which is why the two changes are in
  one commit

• under remote.origin.tagOpt=--tags, this branch leaves the local tag list
  empty where master's script pulls in the remote tag

[github-actions]

🟢 PR Severity: LOW

file classification | 1 files | 85 lines changed

🟢 Low (1 files)

• scripts/tag-release.sh - build/release tooling script, not application code

Analysis

This PR only modifies scripts/tag-release.sh, a release tooling script. It does not touch any wallet, channel, HTLC, peer, or other consensus/fund-handling code paths, so it qualifies as best-effort review under the LOW severity tier. No severity bump conditions apply (single file, no critical packages touched).

---

_{To override, add a severity-override-{critical,high,medium,low} label.}