Label version-bump PRs with a shared version-bump label (#208)

* Add a commit status chip showing the version on release-bump commits

When release-on-bump.yml detects an unreleased version, it now also sets a
"version" commit status (e.g. "Bumped to v1.0.101") on that commit before
dispatching the release, so the bump is visible as a chip without opening
the workflow run. Best-effort: a status API failure only warns, it never
blocks the release dispatch.

* Label the bump's PR with the released version instead of a commit status

A PR label (e.g. "v1.0.101") shows on the PR conversation page and in the
PR list, unlike a commit status on the squash commit, which only renders on
the commit page. Resolve the squash commit back to its PR via the
commits/{sha}/pulls API; create the label idempotently before applying it.
Still best-effort: lookup or labeling failures warn and never block the
release dispatch.

* Use one shared version-bump label instead of a label per version

Per-version labels would accumulate in the repo's label list forever; a
single reused "version-bump" label marks every releasing PR without the
clutter. The released version stays visible via the PR title and the tag.

.github/workflows/release-on-bump.yml

@@ -49,6 +49,8 @@ on:
 permissions:
   contents: read
   actions: write # github.token fallback path dispatches release.yml
+  issues: write # to create/apply the version label on the bump's PR
+  pull-requests: read # to resolve the bump commit to its squash-merged PR
 
 jobs:
   dispatch:
@@ -102,6 +104,28 @@ jobs:
             exit 0
           fi
 
+          # Mark the bump's PR with a shared "version-bump" label so releases
+          # are visible from the PR list (one reused label, not one per
+          # version). Best-effort: a labeling hiccup must never block the
+          # release dispatch below.
+          if pr=$(GH_TOKEN="$FALLBACK_TOKEN" gh api "repos/${GITHUB_REPOSITORY}/commits/${GITHUB_SHA}/pulls" \
+            --jq '.[0].number // empty' 2>/dev/null); then
+            if [ -n "${pr}" ]; then
+              # Create the label first (422 if it already exists — ignored) so
+              # the add below never depends on auto-creation behavior.
+              GH_TOKEN="$FALLBACK_TOKEN" gh api "repos/${GITHUB_REPOSITORY}/labels" \
+                -f name="version-bump" -f color="0e8a16" \
+                -f description="Bumps the CLI version; merging cuts a release" >/dev/null 2>&1 || true
+              GH_TOKEN="$FALLBACK_TOKEN" gh api "repos/${GITHUB_REPOSITORY}/issues/${pr}/labels" \
+                -f "labels[]=version-bump" >/dev/null \
+                || echo "::warning::Failed to label PR #${pr} with version-bump"
+            else
+              echo "No PR associated with ${GITHUB_SHA} — skipping the version-bump label."
+            fi
+          else
+            echo "::warning::Could not look up the PR for ${GITHUB_SHA} — skipping the version-bump label."
+          fi
+
           echo "Dispatching release.yml with tag=${tag} (version is unreleased)."
           if [ -n "$DISPATCH_PAT" ] && GH_TOKEN="$DISPATCH_PAT" gh workflow run release.yml --ref main -f tag="${tag}"; then
             echo "Dispatched with RELEASE_DISPATCH_TOKEN — the macOS DMG will attach automatically."