Fix the AM-5 instrument to measure quietly; the breach was not real

T03 reported AM-5 at 87.0 s / 61.3 s and called it a 45% breach of the
60 s target. Re-measured with the fixed instrument on a quiet machine:

  load before measuring: 0.14 per CPU over 8 CPUs — quiet
  dev toolchain (default features)         37.3 s  [ok  target <= 60 s]
    best of 3: 37.3, 42.9, 46.2  (spread 1.24x)
  shipped runtime (--no-default-features)  41.2 s  [ok  target <= 60 s]
    best of 3: 41.2, 50.8, 54.2  (spread 1.32x)

AM-5 is MET with 1.6x headroom. The 87.0 s was measured while the machine
was busy with mutation-check and cargo builds — a timing measurement under
contention measures the contention.

That is the same error class as AM-6's, committed two tasks later in the
same session by the same author, in the row immediately after the one
where it was diagnosed. Knowing the failure mode did not prevent it; only
building the guard did. That is the InnerLoop v1.2 design-goal argument
holding up under a third instance: optimize for cheap correction, because
prevention keeps not converging.

The instrument now refuses to measure above 0.5 load per CPU, takes the
best of 3, and warns when the spread exceeds 1.25x. Best, not worst: a
build-time ceiling asks whether the machine can do it in 60 s, the mirror
of AM-6's best-of-N for a throughput floor. The spread warning fired on
the shipped-runtime samples — consecutive clean builds degrade 37.3 ->
46.2 — so a quiet machine is not a uniform one either.

The escalation to a maintainer decision is withdrawn: there is no breach.
The build profiling done while the breach was believed real is recorded in
the log rather than acted on — 174 s of CPU work at only 3.2x parallelism
on 8 cores, a ~22 s serial proc-macro chain, lto=thin worth ~6 s, and
pinning ppv-lite86 to drop zerocopy making it worse (23 -> 25 crates).
With 1.6x headroom there is nothing to buy.

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

history/260801-cb-wp-0006-log.md

@@ -98,25 +98,58 @@ CB-EV-0001 called "very unlikely to bind" was right — but it is now
 *measured* rather than assumed, and verified red by a property mutation
 (a 300 MB allocation in the workload).
 
-**AM-5: BREACHED, on both readings, on the machine the spec names.**
+**AM-5: ~~BREACHED~~ MET — the first reading was wrong.**
+
+> **Corrected 2026-08-01 (during T04).** T03 reported 87.0 s / 61.3 s and
+> called AM-5 a 45% breach. **It is not.** Re-measured on a quiet machine
+> with the fixed instrument:
+>
+> ```text
+> load before measuring: 0.14 per CPU over 8 CPUs — quiet
+> dev toolchain (default features)         37.3 s  [ok  target <= 60 s]
+>   best of 3: 37.3, 42.9, 46.2  (spread 1.24x)
+> shipped runtime (--no-default-features)  41.2 s  [ok  target <= 60 s]
+>   best of 3: 41.2, 50.8, 54.2  (spread 1.32x)
+> ```
+>
+> **1.6× headroom, comfortably met.** The 87.0 s was measured while the
+> machine was busy running `mutation-check` and cargo builds — a timing
+> measurement under contention measures the contention. That is the *same
+> error class as AM-6's*, committed two tasks later in the same session,
+> by the same author, in the row immediately after the one where it was
+> diagnosed.
+>
+> The instrument now (a) reads `/proc` load average and **refuses to
+> measure** above 0.5 per CPU, and (b) takes the **best of 3** — best, not
+> worst, because a build-time *ceiling* asks "can this machine do it in
+> 60 s", the mirror of AM-6's best-of-N for a throughput *floor*. It also
+> warns when the spread exceeds 1.25×, which fired on the shipped-runtime
+> samples: consecutive clean builds degrade (37.3 → 46.2), so even a quiet
+> machine is not a uniform one.
+
+The original, now-withdrawn finding follows for the record:
 
 ```text
 dev toolchain (default features)             87.0 s  [FAIL target <= 60 s]
 shipped runtime (--no-default-features)      61.3 s  [FAIL target <= 60 s]
 ```
 
-Measured on `bnt-lap001`, 8 cores — the machine `specs/GameKernel.md` §5
-names, so this is a direct comparison, not a directional one. A row
-declared `recorded not gated` and never recorded turns out, on first
-measurement, to **fail its own target by 45%**.
-
 The tool **reports and exits 0**, because the spec says the row is not
-gated. Gating it is a spec change and needs an ADR; a tool that promotes
+gated (and on the corrected number there is nothing to escalate anyway). Gating it is a spec change and needs an ADR; a tool that promotes
 itself is how a target starts binding without anyone deciding it should.
-So AM-5 stays `unmutatable` — for the accurate reason now — and the breach
-is **raised as a maintainer decision**, not resolved here. Three honest
-options: speed the build, move the target by ADR (arguing why 60 s was
-wrong rather than why 87 s is convenient), or withdraw the row.
+So AM-5 stays `unmutatable` — it cannot fail while the spec declares it
+ungated, which is the accurate reason. **The escalation is withdrawn**:
+there is no breach to decide about.
+
+A build profile was investigated anyway while the breach was believed
+real, and the findings stand on their own: 51 compile units, 174 s of CPU
+work compressed into ~54 s wall, **parallelism only 3.2× on 8 cores**
+because `proc-macro2 → syn → serde_derive → serde_core` is a ~22 s serial
+chain. `lto = "thin"` costs ~6 s (55.8 → 49.4 s mean) and is the only real
+lever; pinning `ppv-lite86` down to drop `zerocopy` (the largest single
+unit, 21.8 s) makes it **worse** — 23 → 25 crates, because the older
+version pulls `zerocopy-derive`. Recorded here rather than acted on: with
+1.6× headroom there is nothing to buy.
 
 **The measurement had a real bug, found by cross-validation.**
 `getrusage(RUSAGE_CHILDREN)` is a high-water mark across *every* reaped