Condense CB-WP-0005 T02's note to a pointer at CB-EV-0004

loop-lint failed at 406 lines, third time this file has bumped the ~400
limit. Trimming again would have been the wrong fix: the T02 delivery note
duplicated CB-EV-0004 Test 2 almost verbatim, which is a duplicated fact
in the workplan that most recently added a duplicated-fact gate.

The workplan now holds task definitions and short outcomes; the evidence
file holds the analysis. 395 lines.

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

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

@@ -140,31 +140,20 @@ unmet.**
     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.**
+Two corrections, detailed in [CB-EV-0004](../evidence/CB-EV-0004-assertion-coverage.md)
+Test 2. **There are 14 rows, not 12** — AM-4 splits into a/b/c, so the
+9-of-12 prediction is evaluated as ≥10 of 14. And **the first run's two
+`SURVIVED` verdicts were my own no-op mutations**, either of which would
+have published a false accusation against working code; replaced with real
+inversions, after which both go red. T08's question is answered 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.**
+`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 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`;