docs(remediation): bank D-42 — the head-pin's negative control has never been observed

merge-gate.md says it outright: a successful merge is NOT evidence the pin worked, only the negative
case is. On mosaicstack Gitea a merge against a WRONG head_commit_id has never been attempted, so every
head-pinned merge to date is equally consistent with the pin working and with the pin being ignored.

That is D-23's class — the queue guard "ran" and returned pass for every possible input; the pin
"holds" on every merge that would have succeeded anyway. By the mission's own standard (every
gate-introducing task carries a registered must-fail negative control; a gate with no proven failure
path manufactures evidence) the head-pin is unregistered in substance however it reads in the runbook.

Not blocking #1033: that head is coordinator-frozen with both the orchestrator and coder-mos1 holding,
so there is no concurrent pusher for the pin to defend against — its protection is only load-bearing on
a contested head. Raised by Mos while assigning the merge; Mos owns it and has filed it as an infra
task in the D-37/D-41 cluster, to be proven before any contested-head merge.

Requirement on RM-02: the negative-control clause must cover provider-side enforcement mechanisms, not
only in-repo checks. "The API accepted our parameter" is not evidence the API honours it — the same
true-answer-to-a-different-question shape as D-24 and D-38.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/remediation/BOARD.md

@@ -29,8 +29,8 @@
 
 1. **Nothing is waiting on you that is urgent.** RM-03 waits on Jason; RM-61 is gate-ready and waits on
    Mos; RM-02 unblocks once RM-61 merges. Read the record before touching any lane.
-2. **`docs/remediation/TASKS.md` is authoritative**, not the newest voice in a chat. It holds 42 findings
-   (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-41 + D-38c in TASKS.md), every ruling with its rationale, and the
+2. **`docs/remediation/TASKS.md` is authoritative**, not the newest voice in a chat. It holds 43 findings
+   (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-42 + D-38c in TASKS.md), every ruling with its rationale, and the
    requirements each finding placed on RM-02/RM-34/RM-50/RM-55.
 3. **`MISSION.md` carries five first-class principles**, all earned by live failures — observe the
    property not the proxy · pre-registration prevents retrofitting and nothing else · never ship an
@@ -91,7 +91,7 @@ board is one of the six stale restatements below.
 
 ## Decisions log — full record in [`TASKS.md`](./TASKS.md)
 
-All 42 findings (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-41 + D-38c in `TASKS.md`) and every ruling with its
+All 43 findings (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-42 + D-38c in `TASKS.md`) and every ruling with its
 rationale live there. **Not duplicated here** — a second copy is a second thing to go stale, which this
 board had done three times in one night (gate list, capability registry, DECISION-1 status), and three
 more times by the next rotation seam (RM-61 "building", "nothing implemented yet", DECISION-1/2/3

docs/remediation/TASKS.md

@@ -500,6 +500,29 @@ holds the head.** `coder-mos1` was RIGHT to want it fixed and WRONG to try to se
 right again immediately after, ACKing the hold and volunteering unprompted that it held an unpushed
 local commit. That disclosure is the behaviour to reinforce.
 
+### D-42 — the head-pin is an enforcement mechanism whose NEGATIVE CONTROL has never been observed
+
+`merge-gate.md` states it directly: **a successful merge is NOT evidence the pin worked.** Only the
+negative case is — a merge attempted against a WRONG `head_commit_id` must be refused (409). On
+mosaicstack Gitea **that negative case has never been run.** Every head-pinned merge to date is
+consistent with the pin working _and_ equally consistent with the pin being ignored.
+
+**This is D-23's class exactly** — the queue guard "ran" and returned pass for every possible input.
+Here the pin "holds" on every merge that would have succeeded anyway. By the mission's own standard —
+_"every gate-introducing task carries at least one registered must-fail negative control; a gate with no
+proven failure path manufactures evidence"_ — the head-pin is currently **unregistered in substance**,
+however it reads in the runbook.
+
+**Not blocking `#1033`:** that head is coordinator-frozen with both the orchestrator and `coder-mos1`
+holding, so there is no concurrent pusher for the pin to defend against. The pin's protection is only
+load-bearing on a **contested** head. Raised by Mos while assigning the merge, and **Mos owns it** —
+filed as an infra task in the **D-37 / D-41 cluster**, to be proven BEFORE any contested-head merge.
+
+**Requirement it places on RM-02:** the registry's negative-control clause must cover **provider-side
+enforcement mechanisms**, not only in-repo checks. A gate whose enforcement lives in the forge is still
+a gate, and "the API accepted our parameter" is not evidence the API _honours_ it — the same
+true-answer-to-a-different-question shape as D-24 and D-38.
+
 ### D-38c — PR metadata failed a THIRD time on the same PR, and the process gap behind it
 
 The merge-gate returned **NO-GO on `#1033`** with every code and CI gate verified — including the