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/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