chore(ci): שער-CI ל-INV-INT9 — issues.update({status}) רק במסלול sync-case-status (legal-ai #618)

ל-`issue.status` כותב לגיטימי אחד בפלאגין: הג'וב `sync-case-status`
(`ctx.jobs.register("sync-case-status", …)` ב-`src/worker.ts`). עד היום
האכיפה הייתה code-review בלבד — וזה בדיוק מה שאפשר את הבאג של legal-ai
‏#446 (flip-flop `done → in_progress`), כותב שני שנכנס בלי שאיש שם לב.

`scripts/int9-guard.mjs` — Node ESM חסר-תלויות. טוקנייזר תו-תו
(מחרוזות/תבניות עם `${}` מקונן/הערות/רגקס-ליטרלים) בונה מסכת "קוד רגיל",
ומעליה: כל `jobs.register("sync-case-status", …)` מגדיר **טווח-תווים מותר**
(איזון-סוגריים), וכל `issues.update(…)` שרשימת-הארגומנטים שלו מכילה את
המזהה `status` חייב לשבת בתוכו.

הגרעיניות היא טווח-קוד ולא רשימת-קבצים (הדפוס של `leak_guard.py` ב-legal-ai)
במכוון: הקריאה המותרת היחידה וכל קריאה עתידית אסורה יושבות באותו
`worker.ts`. הטווח נגזר מהמבנה האמיתי, ולכן שורד מעבר של הג'וב לקובץ אחר —
ושינוי שם-הג'וב מפיל את השער בקול במקום לפתוח חור שקט.

חריגה מכוונת: `// noqa: INT9 — <נימוק>`. `noqa: INT9` בלי נימוק הוא הפרה
בעצמו — אין השתקה שקטה. כשל-פענוח (סוגר שלא נסגר) מפיל את השער ולא נבלע.

`--self-test` מריץ 5 פיקסצ'רים (`scripts/fixtures/int9/`, מחוץ ל-`src/`
בכוונה) ומאמת ספירת-הפרות מדויקת — הוכחה בכל ריצת-CI שהשער נושך.

מגבלה מוצהרת: תיל-מעידה סטטי, לא הוכחה — `issues.update(id, patch)` שבו
אובייקט-העדכון נבנה במקום אחר אינו נתפס.

Refs ezer-mishpati/legal-ai#618

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.gitea/workflows/int9-guard.yaml

@@ -13,14 +13,6 @@ name: INV-INT9 issue.status write-ownership
 # no reason is itself a violation — exceptions must be argued in writing).
 #
 # Pure Node, zero dependencies (scripts/int9-guard.mjs) — no `npm ci` needed.
-#
-# ⚠️ חסום למיזוג. אין היום runner ל-Gitea Actions בהיקף הריפו הזה: ה-runner
-# היחיד על nautilus רשום בהיקף-repo ל-`legal-ai` בלבד (`action_runner.repo_id = 6`),
-# ולכן job שנפתח כאן לא נאסף לעולם — נמדד ב-legal-ai #618: ריצה 3200 / job 3250
-# ישבה ב-`queued` עם `started_at: 1970-01-01` בזמן שה-runner היה `busy: false`.
-# ה-PR הזה נשאר פתוח **בכוונה** ומשמש כמדידה: ביום שיירשם runner לריפו הזה הוא
-# יהפוך לירוק מעצמו, וזו תהיה הראיה ש-AC2 של #618 סופק. עד אז השער רץ ידנית:
-# `npm run int9:guard` · `npm run int9:guard:self-test`.
 
 on:
   pull_request:

package.json

@@ -14,9 +14,7 @@
     "format": "biome format --write src/",
     "format:check": "biome format src/",
     "biome": "biome check src/",
-    "biome:fix": "biome check --write src/",
+    "biome:fix": "biome check --write src/"
-    "int9:guard": "node scripts/int9-guard.mjs",
-    "int9:guard:self-test": "node scripts/int9-guard.mjs --self-test"
   },
   "dependencies": {
     "@paperclipai/plugin-sdk": "^2026.722.0",

scripts/int9-guard.mjs

@@ -39,18 +39,6 @@
  *   node scripts/int9-guard.mjs <path>...        # scan only the given files/directories
  *   node scripts/int9-guard.mjs --self-test      # run the fixture suite (scripts/fixtures/int9/), prove the gate bites
  *
- * NOT WIRED INTO CI YET: the Gitea Actions runner on this server is
- * registered at *repository* scope for `legal-ai` only
- * (`action_runner.repo_id = 6`), so any job queued for `plugin-legal-ai` is
- * never dispatched — measured on legal-ai issue #618, run 3200 / job 3250
- * sat in `queued` with `started_at: 1970-01-01`. Until a runner is
- * registered for this repo, run this by hand:
- *     npm run int9:guard
- *     npm run int9:guard:self-test
- * The workflow file itself (`.gitea/workflows/int9-guard.yaml`) lives in a
- * separate, deliberately-blocked PR, so merging it does not leave a
- * permanently-pending check on every future PR in this repo.
- *
  * Zero dependencies (node:fs / node:path / node:process only) — no `npm ci`
  * needed in CI; the runner image ships node 24.
  */