fix(release): notes must not open with the bot commit; guard matches the subject (t44 3b/3c)

t45's review of the release versioning found three lows; two touch behaviour here (the
third, README wording, is the next commit).

R1 — with a write-back the tag points at the bot's own commit, so the notes range
`PREV..TAG` published "- chore(release): vX [skip ci]" as the first line of every
release. The range now ends at `${TAG}^` when BUMP=yes (the last commit a developer
wrote) and at `${TAG}` when it is not (there the tag IS the pushed commit, and it
belongs in the notes). `git describe` for the previous tag is unchanged: it already
started from `${TAG}^`, so it keeps naming the previous release.

R3 — the job guard matched the `[skip ci]` marker ANYWHERE in the commit message, so a
developer commit whose body merely mentioned it silently skipped its own release. The
guard is now anchored to the release commit's subject prefix
(`!startsWith(message, 'chore(release):')`), which is a structural property, not a
substring a body can trip. The marker stays in the commit message: it is the
convention Gitea itself may honour to skip the run outright, and the README now says
so, together with the fact that the job guard is the layer that holds when it does not.

3c — the resolver's tests used tag fixtures, so `refs/tags/X^{commit}` was never
exercised, and that dereference is the entire reason an annotated tag is recognised
(for one, `git rev-parse refs/tags/X` is the TAG OBJECT, not the commit, so a
comparison that forgot to dereference would miss a released commit). The resolver now
also runs inside real temporary repositories built with real annotated and lightweight
tags: released-on-HEAD both ways, a tag on an older commit falling back to the date,
no tags at all, the same-day scan walking real tags, and gap reuse. The workflow's own
run: scripts are executed too — extracted from the YAML by hand rather than with a
parser the fast suite does not have — covering the bump/verify/tag path (commit
subject, tag == HEAD, the tag's manifest, the pushed tag), the inconsistent-manifest
refusal, the rejected-push failure, and the notes range: with BUMP=yes the fixed range
yields "- feat: the real change" while the range it replaced demonstrably contains
"- chore(release):". The job-level `if:` itself cannot be executed here (no Gitea
runner) and stays a contract pin; the script-side layer that makes a bypassed guard
harmless is executed instead.

Verified: 414 passed / 2 skipped, ruff clean, release.yml parses.

.gitea/workflows/release.yml

@@ -47,15 +47,18 @@ env:
 jobs:
   release:
     runs-on: ubuntu-latest
-    # t42: this job pushes the write-back commit itself, and a run starting from
-    # that commit would release the same version twice. Two layers guard it: the
-    # commit message carries the conventional `[skip ci]` marker, and this
-    # condition re-checks the pushed message, so the guard still holds if a Gitea
-    # version stops honouring the marker. workflow_dispatch has no head_commit,
-    # hence the first clause.
+    # t42/t44 R3: this job pushes the write-back commit itself, and a run starting
+    # from that commit would release the same version twice. The guard is anchored to
+    # the release commit's SUBJECT (`chore(release): …`), not to the `[skip ci]`
+    # marker anywhere in the message: a developer commit whose body happens to
+    # mention [skip ci] must still release — with contains() it silently did not.
+    # The marker stays in the commit message because it is the convention Gitea
+    # itself may honour to skip the run outright (README documents that platform
+    # layer, and that the job guard is a no-op there rather than the trigger).
+    # workflow_dispatch has no head_commit, hence the first clause.
     if: >-
       github.event_name == 'workflow_dispatch' ||
-      !contains(github.event.head_commit.message || '', '[skip ci]')
+      !startsWith(github.event.head_commit.message || '', 'chore(release):')
     steps:
       - uses: actions/checkout@v4
         with:
@@ -151,18 +154,28 @@ jobs:
         env:
           VERSION: ${{ steps.version.outputs.VERSION }}
           TAG: ${{ steps.version.outputs.TAG }}
+          BUMP: ${{ steps.version.outputs.BUMP }}
           SERVER: ${{ github.server_url }}
           REPO: ${{ github.repository }}
           TOKEN: ${{ secrets.GITEA_TOKEN }}
         run: |
           set -euo pipefail
 
-          # Notes: subject lines of the commits in the released range.
-          PREV="$(git describe --tags --abbrev=0 "${TAG}^" 2>/dev/null || true)"
-          if [ -n "$PREV" ]; then
-            RANGE="${PREV}..${TAG}"
+          # Notes: subject lines of the commits in the released range — the
+          # commits a DEVELOPER wrote. With a write-back (BUMP=yes) the tag points
+          # at the bot's own commit, so the range has to stop at its parent or every
+          # release would open with "chore(release): vX [skip ci]". Without one the
+          # tag is the pushed commit itself and belongs in the notes (t44 R1).
+          if [ "$BUMP" = "yes" ]; then
+            NOTES_END="${TAG}^"
           else
-            RANGE="${TAG}"
+            NOTES_END="${TAG}"
+          fi
+          PREV="$(git describe --tags --abbrev=0 "${NOTES_END}^" 2>/dev/null || true)"
+          if [ -n "$PREV" ]; then
+            RANGE="${PREV}..${NOTES_END}"
+          else
+            RANGE="${NOTES_END}"
           fi
           {
             echo "Release ${TAG}"