docs(backlog): file the zizmor self-repository red on cla.yml (BACKLOG #1457)

docs/BACKLOG.md

@@ -22969,3 +22969,23 @@ git rev-parse --git-dir
 
 **A NOTE ON REPRODUCING THIS, because the first framing did not reproduce and that nearly buried it.** A reader in their own worktree who lists their own project directory will find exactly one session UUID and correctly conclude that nothing is shared with other seats. That result is right and it is not a refutation: the collision is inside one session, so the reproduction is to write a marker into the scratchpad and then spawn a subagent to list that same directory. **The two colliding paths are deliberately not published here** -- they carry a host account name and worktree slugs, which the forbidden-content gate blocks and which its own message says must be removed rather than allowlisted. The schematic form above is the publishable version.
 
+## 1457. zizmor 1.30.0 flags cla.yml self-repository, and the bump that introduced it merged with its own gate red
+
+> 🔢 **Filed 2026-09-05 (handoff-review-1211-f6d05b), found while attributing a red on PR 901 rather than looked for.** Value **5/10** - Difficulty **3/10**. **`main` CARRIES A ZIZMOR RED THAT NOTHING WILL CLEAR ON ITS OWN.** Dependabot's #891 bumped `zizmor==1.29.0` to `1.30.0` in `ci/locks/ci-scanners.lock`. That release added the `self-repository` audit, which fires LOW on `.github/workflows/cla.yml:102` -- the vendored local action is referenced as `uses: ./.github/actions/cla-assistant-lite`, and the audit wants what its help text calls GitHub's dedicated self-repository syntax. The job exits 12 on any finding, so one LOW fails it.
+>
+> **THE GATE RAN ON THE BUMP AND WAS MERGED PAST, which is the part worth filing.** #891's own zizmor run 33945900593 finished 2026-09-05T04:57:02Z with `79 findings (30 ignored, 48 suppressed, 1 safe fixes): 0 informational, 1 low, 0 medium, 0 high` and `exit code 12`. The pull request merged at 21:02:26Z, about sixteen hours later. **This was not a protection bypass:** read from the server that day, `zizmor (GitHub Actions static analysis)` is NOT among the thirteen required contexts, `autoMergeRequest` was null, and the merge was an ordinary one. An advisory check went red and nobody was obliged to stop. That is the finding -- not misconduct, a gate whose redness costs nothing.
+>
+> **MEASURED, AND THE INSTRUMENT WAS NOT `main`.** `main` has not run zizmor since the bump; its last run is 2026-09-05T09:35:09Z at `b9d204e38`, green, and it predates #891's merge. What was measured is stronger than a prediction and is stated as what it is: PR 901's run 33992002941 executed **main's own pinned scanner** (`origin/main:ci/locks/ci-scanners.lock` reads `zizmor==1.30.0`) against **main's own `cla.yml`** -- the blob is byte-identical on both, `a4d4e1e98a5c2bcd255b615b93ec8c440aed2f03` -- and reported the same single LOW. The remaining step to `main` going red is that its 06:00 UTC cron runs those same two inputs. Confirm rather than assume: `gh run list --workflow zizmor.yml --branch main --limit 1`.
+>
+> **THE REMEDY IS NOT KNOWN AND MUST NOT BE GUESSED.** zizmor's help says *"use '$/...' instead of './...'"* and marks the finding auto-fixable. **That syntax was NOT verified against GitHub's own documentation by this filing**, and it is quoted as the tool's claim rather than repeated as fact. Verifying it IS the work. At least three ends are available and they are not equivalent: adopt the syntax if it is real and supported by the runner in use; suppress `self-repository` for this file in `.github/zizmor.yml` with a reason, the way four `dangerous-triggers` entries already are; or record it as an accepted residual beside the `archived-uses` entry that already exists for this same file at `cla.yml:44`.
+>
+> **WHY THE ONE-CHARACTER FIX IS THE DANGEROUS ONE, and this is the constraint that sets the difficulty rather than the edit size.** `cla` IS a required context, `cla.yml` runs on `pull_request_target`, and **a `pull_request_target` workflow cannot be tested by the pull request that changes it** -- its runs execute the copy on the default branch, so the change lands on `main` untested. A wrong edit then breaks every contribution, and the repair for it is itself a pull request gated by the check it broke. That deadlock has happened here once already, on PR 621, and it needed an administrator. `scripts/quality/workflow_local_action_check.py` exists because of it and records the whole sequence in its header. Whoever takes this should read that first.
+>
+> **ONE STALE LINE FOUND IN PASSING.** `.github/workflows/zizmor.yml`'s header says a bump pull request touching only `pyproject.toml` and the lock *"never ran this gate"*, citing PR #66. That is no longer true: the workflow's `pull_request` trigger now carries `paths: [".github/**", "ci/locks/ci-scanners.lock"]`, so #891 did run it -- and did fail it. The header's conclusion, that a version jump is first adjudicated somewhere other than the bump PR, survives in a different form: the gate ran, and being advisory, it did not adjudicate anything.
+>
+> Verdict: build
+> Research: whether `$/` is real, supported GitHub Actions syntax for a local action, and on which runner images
+> Closing-act: code
+
+**Cluster:** repository security gates. **Priority:** P3. **Verdict:** build.
+**Severity:** no deployment axis (sec. 0), no engine behaviour, no PHI axis, and nothing reaches a shipped wheel. The cost is a **control losing its meaning**: a scanner that is red for a reason nobody intends to act on trains its readers to skip it, and the next real finding arrives in a job that has been failing for weeks. That is the same pathology BACKLOG #1413 records for a signal reporting against a standard nothing enforces, and it is why this is filed rather than left to the next person who notices a red.