CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced

For each acceptance row in GameKernel §5, invert the property and require
the verifying command to go red. adapted:mutation-testing, with the
denominator changed from source lines to acceptance rows.

  M-D1-MUT: 4/14 rows enforced
    PARTIAL       2   (AM-7, AM-8 — some clauses live, some inert)
    unmutatable   8   (no property to invert, reason stated per row)
    SURVIVED      0

Two corrections to our own numbers. There are 14 rows, not the twelve
ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the
prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly
unmet. No target moved in this commit.

The second correction matters more. My first run reported two SURVIVED
rows and both were my own no-op mutations: `pub struct NullRng;` ->
`pub struct NullRng {}` is semantically identical, and renaming
max_age_days does nothing because CA-17 reads it with a default of 90.
Both would have been published as "this row asserts nothing" — a false
accusation against code that is fine. Replaced with real inversions (a
per-construction counter in the ChaCha seed; reverting AC-9's output
resolution to the first-wins bug it was fixed for), after which both go
red. T08 asks whether writing a weak mutation is the new grep. It is,
demonstrably, on the first attempt.

The finding is larger than the workplan assumed. 8 of 14 rows are
unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no
instrument at all. AM-6 is the sharpest: nothing in the workspace
compares any number to 100,000 events/s, the headline throughput claim.
The problem is not three unimplemented rules, it is that more than half
the acceptance table has nothing behind it.

Harness controls: a stale find-string reports HARNESS-BROKEN rather than
scoring the baseline as the mutant; a red baseline reports inconclusive
rather than red; the tree is restored in a finally and the restoration is
verified. Not in `make all` — it rebuilds the workspace once per row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/CB-WP-0005-assertion-coverage.md

@@ -138,6 +138,52 @@ than claimed, the finding shrinks to three absent rules, and M-D1-MUT was
 not worth its CI cost); **3 of 12 means the pass is under-scoped and must
 stop and re-plan** rather than proceed to Phase C.
 
+**Delivered. Measured: 4 of 14 rows enforced. The prediction is badly
+unmet.**
+
+```text
+  M-D1-MUT: 4/14 rows enforced
+    PARTIAL       2      (AM-7, AM-8 — some clauses live, some inert)
+    unmutatable   8      (no property to invert, reason stated per row)
+    SURVIVED      0
+```
+
+**First correction: there are 14 acceptance rows, not 12.** ADR-0005 and
+this workplan both said twelve; AM-4 splits into a/b/c. The 9-of-12 (75%)
+prediction is evaluated as ≥10 of 14 on the same basis. Measured 4 (29%).
+
+**Second correction, and the one that matters: my first run reported two
+SURVIVED rows, and both were my own bad mutations.**
+
+- AM-8: `pub struct NullRng;` → `pub struct NullRng {}` — semantically
+  identical, a no-op.
+- AM-12: renaming `max_age_days` in the price sheet — CA-17 reads it with
+  `.get("max_age_days", 90)`, so removing it changes nothing.
+
+Both would have been published as *"this row asserts nothing"* — a false
+accusation against code that is in fact fine. Replaced with real
+inversions (inject a per-construction counter into the ChaCha seed;
+revert the AC-9 output resolution to the first-wins bug it was fixed for),
+after which both go red. **T08's question — "is writing a weak mutation
+the new grep?" — is answered on the first attempt: yes, demonstrably.**
+
+**The finding is larger than the workplan assumed.** 8 of 14 rows are
+`unmutatable`: AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no
+instrument at all. AM-6 is the sharpest — **nothing in the workspace
+compares any number to 100,000 events/s**, the headline throughput claim.
+The problem is not three unimplemented rules; it is that **more than half
+the acceptance table has nothing behind it.**
+
+Harness controls that earned their place: a stale find-string reports
+`HARNESS-BROKEN` rather than silently scoring the baseline as the mutant;
+a red baseline reports `inconclusive` rather than `red`; the tree is
+restored in a `finally` and the restoration is verified.
+
+`make mutation-check` is deliberately **not** in `make all` — it rebuilds
+the workspace once per mutated row. `--self-test` is in `make self-tests`.
+
+**Stop condition: see the note in T07 and the decision recorded there.**
+
 ## Phase B — correct the record
 
 ## Task: correct three committed verdicts and restore the fourth