CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured

AM-4c is withdrawn from the acceptance table and retained as a reported
diagnostic. GameKernel §5a carries the argument.

The ratio has no monotone better direction. INTENT's rule is "own the
semantics, assimilate the implementation": rising can mean owning
semantics properly or reimplementing what should have been assimilated;
falling can mean leverage or dependency bloat. A target requires knowing
which way is better. It is also redundant — AM-4a/AM-4b bound the
denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two
already-targeted quantities.

Measured at withdrawal: 1,426 own lines per 100k third-party (shipped),
1,107 (dev). make dep-weight now prints both, labelled diagnostic — the
row was never actually reported before.

M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the
output. Dropping it would move the score 7/14 -> 7/13 without enforcing
anything: a score improved by deleting the question.

Decided before Phase B deliberately, since ADR-0005 predicts own-source
growth that will move this ratio; deciding after would be the retarget
§Step 4 forbids.

A T01 correction found here. The AM-6 gate failed inside `make all` at
38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test
runs binaries and threads concurrently. A throughput assertion inside a
parallel harness measures contention, not throughput. T01's measurement
was valid; its gate placement was not.

Fixed by running it only where valid — #[ignore] plus `make am6` in
release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not
by lowering the target, which T01 forbade. My first attempt did drift that
way, adding a debug "sanity floor" of 50,000, and was backed out: a second
threshold is still a second chance to tune.

The mutation then went SURVIVED on the first run after the move. 4,000
black_box iterations were calibrated against debug's 3.4x headroom and are
invisible against release's 20x. Raised to 100,000; back to red. A weak
mutation is not a fixed property of a row — it can become weak when the
row's measurement conditions change.

Tier S (amends one row, creates no capability), chaos d4=2, no override.

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

workplans/CB-WP-0006-instrument-the-table.md

@@ -246,6 +246,51 @@ kernel work in Phase B, so AM-4c will move against us. Setting its
 threshold *after* seeing that movement would be the retarget InnerLoop
 §Step 4 forbids — so it is set here, before Phase B, or not at all.
 
+**Delivered: withdrawn from the acceptance table, retained as a
+diagnostic.** `specs/GameKernel.md` §5a carries the argument.
+
+**The ratio has no monotone better direction.** INTENT's rule is *own the
+semantics; assimilate the implementation*. Rising can mean owning
+semantics properly, or reimplementing what should have been assimilated.
+Falling can mean good leverage, or dependency bloat. A target requires
+knowing which way is better, and this metric does not.
+
+**It is also redundant:** AM-4a/AM-4b bound the denominator and AM-2 bounds
+own-source density per rule. AM-4c is a ratio of two already-targeted
+quantities.
+
+Measured at withdrawal: **1,426** own lines per 100k third-party (shipped),
+**1,107** (dev). `make dep-weight` now prints both, labelled
+`diagnostic, not targeted` — it was never actually reported before.
+
+**M-D1-MUT keeps AM-4c in its denominator, deliberately**, and says so in
+the output. Dropping it would move the score 7/14 → 7/13 without enforcing
+anything: a score improved by deleting the question.
+
+### A T01 correction found here
+
+**The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280
+measured in isolation — a 9× drop.** `cargo test` runs test binaries and
+threads concurrently, so **a throughput assertion inside a parallel
+harness measures contention, not throughput.** T01's measurement was valid
+and its gate placement was not.
+
+Fixed by running the measurement only where it is valid — `#[ignore]`,
+plus `make am6` in release with `--test-threads=1`, now **2.0M ev/s,
+20.2× headroom** — and *not* by lowering the target, which T01 explicitly
+forbade and which would have reproduced the defect being fixed. My first
+attempt did drift that way (a debug "sanity floor" of 50,000) and was
+backed out: a second threshold is still a second chance to tune.
+
+**And the mutation went `SURVIVED` on the first run after the move** —
+4,000 `black_box` iterations were calibrated against debug's 3.4×
+headroom and are invisible against release's 20×. Raised to 100,000; back
+to `red`. A weak mutation is not a fixed property of a row: **it can
+become weak when the row's measurement conditions change.**
+
+**M-D1-MUT: 7 of 14** (unchanged — AM-4c was always going to stay
+uncounted; what changed is that the reason is now correct and recorded).
+
 ## Phase B — the kernel work inherited from CB-WP-0005
 
 > These three were written in [CB-WP-0005](CB-WP-0005-assertion-coverage.md)