ci(plugin): gate plugin/** — the path that shipped two live defects

`plugin/` is not built into the image; installs fetch it from this repo via
.claude-plugin/marketplace.json, so a push IS the release. It was absent
from the workflow's `paths:` filter entirely, meaning plugin changes ran no
CI at all. Two separate defects reached a live install through that gap:

  #2198 — all four hook scripts inert (lowercase userConfig env vars,
          line-oriented `jq -rR`, line-oriented `cut -c`)
  #2209 — the fix for #2198 couldn't reach an install because the manifest
          version wasn't bumped, so the installer never refreshed its cache

Adds `plugin/**` + `.claude-plugin/**` to `paths:` and a `plugin` job
running scripts/check_plugin.py:

1. `bash -n` on every hook.
2. The three known-bad patterns from #2198. Verified by replay against
   c569cdd^ — all three are caught. Narrow by design; see below.
3. Shipped plugin content differs from origin/main => the manifest version
   must differ too. Stated against the base branch, not per-commit, so a
   batch needs one bump rather than one per commit. Replayed against
   c569cdd: correctly fails.

The checker found a real outstanding bug on its first run: the `cut -c1-2000`
prompt cap in scribe_autoinject.sh was still line-oriented. Only the
prior-art hook's copy got fixed in c569cdd. Now `head -c`. It then failed
on this very commit for a missing version bump, which is the third time
that rule has mattered and the first time something other than memory
enforced it. Manifest bumped to 0.1.20.

WHAT THIS DOESN'T COVER, and why. shellcheck is the right tool for check 2
and is NOT in ci-python; nor is jq, which every hook requires and silently
bails without — so a "runs and stays silent" smoke test would pass
vacuously today and prove nothing. Both need those two packages added to
the CI image in the CI-runner repo, which is a separate change to a
separate repo (rule #5: the toolchain comes from the image, not from
apt-get at job start). Verified against CI-runner's Dockerfile and
scripts/install-common.sh rather than assumed (rule #37).

`plugin` is not in the build job's `needs`: the plugin doesn't ship in the
image, and blocking the build wouldn't un-publish a bad hook — the push
already did. A failed job still reddens the run.

Closes #2204

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs

.forgejo/workflows/ci.yml

@@ -48,6 +48,15 @@ on:
       - "Dockerfile"
       - "assets/**"
       - "fable-mcp/**"
+      # The plugin ships straight from this repo — installs fetch it via
+      # .claude-plugin/marketplace.json, NOT from the image. So a push here is
+      # the release, with no build step in between. Omitting these paths meant
+      # plugin changes triggered no workflow at all, which is how #2198's three
+      # broken hooks and then #2209's missing version bump both reached a live
+      # install. See the `plugin` job below.
+      - "plugin/**"
+      - ".claude-plugin/**"
+      - "scripts/check_plugin.py"
       - ".forgejo/workflows/ci.yml"
   # Manual trigger from the Forgejo Actions UI. Useful when an image has
   # been built but the deployment didn't pick it up, or when re-running
@@ -102,6 +111,34 @@ jobs:
         run: npx vue-tsc --noEmit
         working-directory: frontend
 
+  # Guards the one part of this repo that ships to users without a build step.
+  # See scripts/check_plugin.py for what it checks and, as importantly, what it
+  # can't check yet (shellcheck and jq are absent from ci-python).
+  plugin:
+    name: Plugin hooks
+    if: github.ref == 'refs/heads/dev' || github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v')
+    runs-on: python-ci
+    container:
+      image: git.fabledsword.com/bvandeusen/ci-python:3.14
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          # The version-bump check diffs shipped plugin content against
+          # origin/main, so it needs history — a shallow clone can't resolve it
+          # and the check would fail loudly rather than pass blind.
+          fetch-depth: 0
+
+      # On main the comparison is against itself, so only the syntax and
+      # pattern checks are meaningful there.
+      - name: Check plugin hooks and manifest
+        run: |
+          if [ "${{ github.ref }}" = "refs/heads/main" ]; then
+            python3 scripts/check_plugin.py --no-version
+          else
+            git fetch --no-tags origin main:refs/remotes/origin/main
+            python3 scripts/check_plugin.py
+          fi
+
   lint:
     name: Python lint
     if: github.ref == 'refs/heads/dev' || github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v')
@@ -228,6 +265,12 @@ jobs:
 
   build:
     name: Build & push image
+    # `plugin` is deliberately NOT in needs. The plugin isn't in the image —
+    # installs fetch it from git — so gating the server image on a hook lint
+    # would couple two things that don't ship together, and blocking the build
+    # wouldn't un-publish a bad hook anyway: the push already did that. A failed
+    # `plugin` job still turns the whole run red, which is the signal that
+    # matters.
     needs: [typecheck, lint, test]
     # Build on dev, main, and v* tag pushes. dev → :dev, main → :latest,
     # tag → :latest + :<version>; every build also gets an immutable :<sha>.