fix: let a fixed PR title clear the title gate (#959)

The title check ran only on opened/synchronize/reopened/ready_for_review, so
editing the title -- the one thing the red check asks for -- produced no new
run and the check kept reporting the old title. A gate whose own remedy does
not clear it teaches people to silence it instead: #950, #952, #953 and #957
each independently proposed making the check skip for Sentinel:/Bolt:/Palette:
titles, which are the exact titles it exists to catch.

Moved to its own workflow so `edited` can be a trigger. It could not be one in
ci.yml, where it would have re-run the whole lint/test matrix on every
description change. This also drops the second, permanently skipped check of
the same name that ci.yml's pull_request_target trigger left on every PR.

Ports mcp-core#718, keeping this repo's pinned harden-runner SHA.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: n24q02m

.github/workflows/ci.yml

@@ -27,44 +27,8 @@ permissions:
   pull-requests: write
 
 jobs:
-  # ============================================================================
-  # PR Title Lint (Conventional Commits subset)
-  # ============================================================================
-  # Squash-merge uses the PR title as the commit subject and bypasses the
-  # local enforce-commit pre-commit commit-msg hook (bot PRs never run local
-  # git hooks). Without a server-side check, a bot title like
-  # "Sentinel: [HIGH] Fix ..." squash-merges with a non-conventional subject
-  # -> PSR's commit parser silently ignores it -> no version bump, even for a
-  # security fix. This job only surfaces a red check; it does not block
-  # merge (no required-status-check rule), so the person merging still must
-  # retype the squash-commit subject to start with fix:/feat: when this is red.
-  pr-title:
-    name: Validate PR title (Conventional Commits subset)
-    if: github.event_name == 'pull_request'
-    runs-on: ubuntu-latest
-    permissions:
-      pull-requests: read
-    steps:
-      - name: Harden Runner
-        uses: step-security/harden-runner@9af89fc71515a100421586dfdb3dc9c984fbf411 # v2.19.4
-        with:
-          egress-policy: audit
-
-      - uses: amannn/action-semantic-pull-request@48f256284bd46cdaab1048c3721360e808335d50 # v6.1.1
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          # Repo rule: only feat: and fix: (feedback_commit_prefix.md). This is
-          # narrower than PSR's own default allowed_tags (which also treats
-          # perf: as patch-worthy) -- we enforce the project convention here,
-          # not just what PSR itself would accept.
-          types: |
-            fix
-            feat
-          requireScope: false
-          subjectPattern: ^(?![A-Z]).+$
-          subjectPatternError: |
-            The subject must not start with an uppercase character.
+  # PR title validation lives in pr-title.yml -- it needs the `edited` trigger,
+  # which would re-run this whole matrix on every description change.
 
   lint-and-test:
     name: Lint & Test (Python ${{ matrix.python-version }}, ${{ matrix.os }})

.github/workflows/pr-title.yml

@@ -0,0 +1,59 @@
+name: PR Title
+
+# Squash-merge uses the PR title as the commit subject and bypasses the local
+# enforce-commit pre-commit commit-msg hook (bot PRs never run local git
+# hooks). Without a server-side check, a bot title like
+# "Sentinel: [HIGH] Fix ..." squash-merges with a non-conventional subject ->
+# PSR's commit parser silently ignores it -> no version bump, even for a
+# security fix. This job only surfaces a red check; it does not block merge (no
+# required-status-check rule), so the person merging still must retype the
+# squash-commit subject to start with fix:/feat: when this is red.
+#
+# It lives in its own workflow so that `edited` can be a trigger. In ci.yml it
+# could not: `edited` fires on every title and description change, and there it
+# would have re-run the whole lint/test matrix each time. Without `edited` the
+# check was unclearable -- fixing the title, which is exactly what the red
+# check asks for, produced no new run, so the check kept reporting the old
+# title forever. A gate whose own remedy does not clear it teaches people to
+# ignore it, or to silence it: #950, #952, #953 and #957 each independently
+# proposed making this check skip for bot-prefixed titles, which are the exact
+# titles it exists to catch.
+#
+# ci.yml also listens on pull_request_target, where this job's `if` left a
+# second, permanently skipped check of the same name on every PR.
+
+on:
+  pull_request:
+    branches: [main]
+    types: [opened, edited, synchronize, reopened, ready_for_review]
+
+permissions:
+  contents: read
+
+jobs:
+  pr-title:
+    name: Validate PR title (Conventional Commits subset)
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: read
+    steps:
+      - name: Harden Runner
+        uses: step-security/harden-runner@9af89fc71515a100421586dfdb3dc9c984fbf411 # v2.19.4
+        with:
+          egress-policy: audit
+
+      - uses: amannn/action-semantic-pull-request@48f256284bd46cdaab1048c3721360e808335d50 # v6.1.1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          # Repo rule: only feat: and fix: (feedback_commit_prefix.md). This is
+          # narrower than PSR's own default allowed_tags (which also treats
+          # perf: as patch-worthy) -- we enforce the project convention here,
+          # not just what PSR itself would accept.
+          types: |
+            fix
+            feat
+          requireScope: false
+          subjectPattern: ^(?![A-Z]).+$
+          subjectPatternError: |
+            The subject must not start with an uppercase character.