Resolve release tags to the peeled commit hash, not the annotated tag object hash

Two places in this repo resolve `refs/tags/` to a SHA without peeling the tag.
For annotated or signed tags this returns the hash of the tag object itself, not the commit the tag points to.
Annotated tags are the normal case here, not an edge case: the release flow's own instructions tell the maintainer to run `git tag -s`, which always creates a tag object.

The herald Haskell CLI is not affected.
It only creates lightweight tags (`gitTag` in `herald/src/Herald/Git.hs`) and never resolves an existing tag to a SHA.
The fix is limited to the two shell surfaces below.

### 1. `actions/herald-release/action.yml` (line ~287): CHaP submission snippet pins the wrong hash

The release PR body embeds a copy-paste snippet for submitting the package to CHaP:

```bash
TAG_SHA=$(git ls-remote __REPO__ refs/tags/__TAG__ | cut -f1)
./scripts/add-from-github.sh __REPO__ "$TAG_SHA"__SUBDIR__
```

`git ls-remote refs/tags/` returns the tag object SHA for annotated tags.
Since the snippet two steps earlier instructs the maintainer to create the tag with `git tag -s`, the SHA passed to CHaP's `add-from-github.sh` is always a tag object hash, never a commit hash.
CHaP then records a hash that is not a commit in the repo's history.

This is the highest-impact site because the hash ends up in the published CHaP metadata.

### 2. `scripts/tag.sh` (lines 73-74): annotated tags break the consistency checks

```bash
tag_commit="$(git rev-parse --quiet --verify "refs/tags/$tag" || true)"
remote_commit="$(git ls-remote --quiet origin --verify "refs/tags/$tag" | awk '{print $1}' || true)"
```

Both values are compared against `head_commit` (a bare commit SHA) to decide whether the tag already sits on the right commit.
For an annotated tag both lookups return the tag object SHA, so a tag that points at exactly the right commit is reported as "Tag already exists on another commit" or "Inconsistent tag and remote tag found".
The script itself creates lightweight tags, so this only bites when a tag was created elsewhere (for example by the signed-tag step of the release flow), which is precisely when the check matters.

### Proposed fix

Peel to the commit at every resolution site (verified locally with git 2.49.0):

- Local: `git rev-parse --quiet --verify "refs/tags/$tag^{commit}"` returns the commit for both annotated and lightweight tags.
- Remote: `git ls-remote "refs/tags/$tag" "refs/tags/$tag^{}"` prints a peeled `^{}` line for annotated tags and only the plain line for lightweight tags.
Take the `^{}` line when present and fall back to the plain line otherwise.
Side note: `--verify` is not an `ls-remote` option at all; in `scripts/tag.sh` it sits after `origin`, so git silently treats it as a pattern that matches nothing.
It can be dropped as part of this change.

### Acceptance criteria

- The CHaP snippet in the release PR body resolves a signed tag to the commit hash the tag points to.
- `scripts/tag.sh` treats an annotated tag pointing at `HEAD` as "already exists", not as an inconsistency.
- Lightweight tags keep working in both places.

Read the resolution sites in actions/herald-release/action.yml around line 287 and scripts/tag.sh around lines 73-74, then review the release snippet and tag consistency checks. Verify annotated and lightweight tags, including an annotated tag pointing at HEAD; done means CHaP receives the peeled commit SHA and scripts/tag.sh recognizes that tag as already existing.

Written by the indexing model from the issue text.