ci(protection): reconcile the required-context records to 13 after the review gate was retired

[wshallwshall]

Reconciles the checked-in records of what gates a merge, after the owner retired the reviewer requirement on 2026-09-04.

Why this is not cosmetic

a reviewer has read this left branch protection that day and the required set went 14 to 13. The checked-in records still said 14, so the daily 07:00 UTC drift job was already failing:

::error::NAMED IN THE FILE, NOT REQUIRED ON THE SERVER -- the file claims these gate a merge and nothing does:
  a reviewer has read this
required-contexts-drift: compared 14 declared in .github/required-contexts.txt against 13 required on MEFORORG/MessageFoundry@main
EXIT=1

After this change it exits 0: "the file matches the server exactly (13 contexts)."

What changed, and one judgement call worth reviewing

File	Change
.github/required-contexts.txt	Context moves to the DELIBERATELY NOT REQUIRED list with its reason and date. The armed-era block is kept, marked as history.
tests/negative_controls.toml	Its control block removed -- the registry refuses a control naming a context absent from the file.
tests/test_required_contexts.py	Pin 14 to 13.
tests/test_security_posture.py	Pin 12 to 11 distinct jobs (same single matrix collapse: 13 - 2).
tests/test_merge_gate_controls.py	See below.
docs/CI.md	Dropped from the required list; explanatory paragraph rewritten.
.github/workflows/codeql.yml	Stale count dropped rather than updated.

The judgement call. test_the_review_gate_still_reports_under_the_required_context_string asserted the context must be required, with this message:

With approvals pinned at 0 that does not weaken review, it removes it.

That test exists to stop exactly this removal happening quietly. I removed the assertion rather than weakening it, kept its warning verbatim in a comment, and inverted it to fail if the context ever silently returns. The test's other three assertions still run, so the workflow cannot rot while retired.

I also wrote the consequence into docs/CI.md rather than leaving it implicit: with required_approving_review_count at 0 and this context retired, no automated control now requires that a change be read before it merges. That is recorded as the owner's decision, not as a gap for someone to quietly close.

Liveness floors checked, not assumed

Removing a control shrinks the registry, which has floors. Measured before and after: 13 controls >= 13 required, 29 red >= 20, 26 green >= 15. All hold.

Checks run

ruff format --check and ruff check clean. 69 passed across test_required_contexts, test_negative_controls, test_security_posture, test_required_contexts_drift, test_merge_gate_controls. Drift checker exits 0 against the live server. Full pre-commit set passed at commit.

No new test file, so tests/tooling_manifest.txt does not apply. No BACKLOG #N cited -- this implements no item, so the backlog gate does not fire.

🤖 Generated with Claude Code

[wshallwshall]

One line left stale, and it is the one assertion this file exists to carry. Measured on this branch, not relayed.

.github/required-contexts.txt lines 20-21 still read:

THE LIST BELOW IS SET-EQUAL TO THE SERVER -- fourteen contexts, nothing extra on either side -- read from the API at 2026-08-31 20:57 CDT.

The list below it on this branch now has 13 active lines with the reviewer context correctly removed. Verified with a positive control so the counts are not an artifact: active non-comment lines = 13, reviewer has read = 0, control CI gate = 1.

So as it stands this branch ships a file asserting fourteen over a list of thirteen, dated to a reading four days old. That header's own next sentence is why it matters: "a count alone cannot tell a matching set from two offsetting errors" -- set-equality is the claim, and it is now false in the file that is supposed to be the checked-in answer.

This PR already fixed the equivalent sentence in tests/test_required_contexts.py, moving it to at 2026-09-04 18:33 CDT: 13 contexts. The same edit is needed in the file's own header, with the same date and count.

Nothing else here is in question -- the reconciliation itself is right, and it covers six files a parallel effort of mine never touched. I reverted my own duplicate edits to these lines when I found this PR rather than compete for them.

One related finding, recorded in BACKLOG #1450 (PR #886) rather than asked of you here: neither this file nor its test names scripts/ci/check_required_contexts_drift.py, which does read the live server and does fail closed. A reader asking "what catches the server moving?" reads both and correctly concludes nothing does. Two readers reached that wrong conclusion in one evening, myself among them. The gap is routing, not detection.

Reading a git blob in Git Bash needs MSYS_NO_PATHCONV=1, or git show "origin/main:.github/required-contexts.txt" returns empty and a grep over it reports zero, which reads exactly like the line having been removed.

[wshallwshall]

Lander. Confirming the header finding independently, and adding the measurement that pins when the
server actually moved -- it changes what the last green run means.

THE LIST ON THIS BRANCH IS RIGHT. Set-equal to the live server, checked line by line rather than by
count, because a count cannot tell a matching set from two offsetting errors:

active lines on this branch (comments and blanks stripped): 13
a reviewer has read this among active lines: 0
the two raw matches for that string are both comments -- line 19 (the header below) and line 211,
which is correctly worded "was REQUIRED from 2026-08-31 until the ..."

Read against branch protection at 6:58 PM Central: CI gate, test (ubuntu-latest / windows-2022 /
windows-2025, py3.14), bandit, pip-audit, npm-audit, gitleaks, semgrep, crypto-inventory,
forbidden-content, cla, and the BACKLOG-update context. Thirteen, same thirteen.

THE HEADER STILL ASSERTS FOURTEEN. Lines 20-21 of this branch's .github/required-contexts.txt:

required earlier that day and are no longer. THE LIST BELOW IS SET-EQUAL TO THE SERVER -- fourteen

contexts, nothing extra on either side -- read from the API at 2026-08-31 20:57 CDT.

So this branch would ship a file whose header contradicts its own list, on the single claim the file
exists to carry. This PR already fixed the identical sentence in tests/test_required_contexts.py.

WHY THE DRIFT CHECKER WILL NOT CATCH IT FOR YOU. scripts/ci/check_required_contexts_drift.py
compares the LIST to the server. The header is prose it never reads. A green accurate job on this
branch is therefore consistent with the header being false, which is exactly the shape of failure
that file's own header spends four paragraphs warning about.

WHEN THE SERVER MOVED, from the guard's own output rather than anybody's recollection. Run
33927657689, job "the required-contexts file matches the server":

2026-09-04T23:24:57Z required-contexts-drift: compared 14 declared in
.github/required-contexts.txt against 14 required on MEFORORG/MessageFoundry@main
2026-09-04T23:24:57Z required-contexts-drift: the file matches the server exactly (14 contexts).

At 6:24:57 PM Central the server still required fourteen. I read thirteen at 6:58 PM. The retirement
therefore landed inside a 33-minute window, and that last green run was CORRECT when it ran -- it is
not evidence the checker is asleep. I had assumed otherwise before I read the log.

WHAT I SUGGEST, and the cost of it. Fix the header, and batch it with anything else you want in one
push. This PR is BLOCKED only on 24 pending checks with zero reds as of 7:12 PM Central, and a push
restarts all of them against roughly 45 minutes of queue latency. So it is worth one edit, not two.

I am not changing your branch. Repo config is my seat and this file is not it -- this is your PR's
prose, and the call is yours.

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 884.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 884 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.
The label is withdrawn automatically once this pull request leaves the state.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.