ci(gate): record the backlog-hygiene promotion (12 → 13 required contexts)

[wshallwshall]

Branch protection now requires 13 contexts — the 12 plus backlog-hygiene, promoted 2026-07-29. .github/required-contexts.txt mirrors the live server, so leaving it at 12 made the file wrong in the one direction it exists to prevent.

The drift test did its job and named all four claims that move with the count: the pin in test_required_contexts.py, docs/CI.md's list, and the "12 status checks" prose in tests/test_push_guard.py and scripts/hooks/push_guard.py. Verified after: the file parses to 13 and is identical to what the API returns.

Promotion pulled a new job under the blocking-posture rules — which is the point

test_security_posture.py resolves each required context to a job, so promoting one subjects that job to every rule in the module for the first time. It immediately flagged backlog-hygiene's gating step for || true.

That one is a false positive, and worth the detail because "fixing" it would have deleted a correct guard:

claim="$(... | grep -oiE 'BACKLOG #[0-9]+' | head -1 || true)"

grep exits 1 on no-match and the script runs under set -euo pipefail, so without || true it aborts on the ordinary "this PR claims no backlog item" path. Inside a command substitution it sets the substitution's status, which the assignment consumes — it cannot reach the step. The gating decision is the explicit exit 0/exit 1 further down. The old message suggested "confine it to its own step", which is impossible for a variable assignment.

So the detector is now precise rather than allowlisted. It scans per line and blanks two things first:

• $( … ) substitutions — what is inside cannot set the step's exit status.
• shell comments — the rationale comments in these workflows quote the idiom being prohibited, so a whole-body scan reports the explanation as the offence. A detector counting itself; third time that shape has appeared in this work.

A standalone gating_cmd || true — the actual hazard — survives both strips.

Proven, not asserted. All three shapes injected into a required job:

injected	result	expected
standalone || true on the gating command	CAUGHT	caught
|| true inside a command substitution	not caught	not caught
|| true inside a comment	not caught	not caught

security.yml verified byte-identical to HEAD afterwards.

The job-count pin moves 10 → 11 (13 contexts collapse to 11 jobs; the three test legs share one matrix job). Still pinned rather than derived, so a matrix split or a context that quietly stops resolving forces a look here instead of passing on a self-consistent count.

The incident this file exists for

Recorded in the header, because it happened within hours of the file landing: on 2026-07-29 protection was briefly reduced to a single required context, dropping all twelve gates while auto-merge stayed armed and approvals stayed at 0. Several PRs merged in that window.

What surfaced it was reconciling a CI wait against required_status_checks.contexts and seeing the count come back as 1 — a monitor waiting for "nothing pending" would have reported green without ever waiting for a test leg, because with one required context there was nothing to wait for. Count what should gate the merge, not what does.

The header also now records that the REST endpoint is all-or-nothing: it 422s with already_exists if any context in the request is already required, and adds none of them.