Handoff: reconcile docs and tooling with the corrections made this session

Session 2 reversed several of its own conclusions. The docs are append-only, so
a reader could land on a superseded section and act on it. This pass makes the
repo internally consistent.

Defects found and fixed in STATUS.md:
- claimed "Hybrid VQ with k=1024: no" as the answer to the linework question,
  directly contradicting FINDINGS 14, which rejected k=1024. Both profiles are
  k=256.
- malformed profile table (six column separators, five columns).
- next-steps list had two items numbered 3 and listed the full-disc survey
  twice.
- the disk-benchmark section still read CRITICAL-PATH with "if SCSI sustains
  >=800 KB/s, ship pixel-exact". That was written while the bandwidth figure
  was misread as 4 MB/s. At 4 Mbps pixel-exact needs 92-97% of the pipe and is
  not available, and the ring-buffer result means the design no longer hangs on
  the benchmark at all. Rewritten with what it IS still worth doing: confirming
  the 4 Mbps provenance, and confirming DMA is used rather than PIO.

FINDINGS now carries supersession blockquotes on 5, 8, 11, 17 and 18 pointing
at the sections that correct them. 18 is the dangerous one -- its peak-vs-
sustained test is reversed by 21 -- so it is marked DO NOT ACT ON THIS SECTION
while noting the per-frame data itself remains valid.

profile_gen.py had the same problem in code: it defaulted to the superseded
peak sizing and returned lam=25 where the docs say lam=10. The buffered test is
now the default and peak sizing is behind --size-for-peak as a bound only. A
tool that contradicts the findings is worse than no tool.

Also preserves the five measurement scripts that produced this session's
numbers as tools/analysis/05-09, following the session 1 precedent, and adds an
"explicitly abandoned -- do not re-propose" list to STATUS covering entropy
coding, k=1024 codebooks and flat 4x4 VQ.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

docs/BENCHMARK.md

@@ -106,20 +106,24 @@ FINDINGS 17.4:
 python3 tools/encoder/profile_gen.py --bw-mbps 4 --name scsi
 ```
 
-It accounts for the three things that eat the pipe before video sees any of it:
-audio (7.8 KB/s), peak-to-mean burstiness (measured 1.4-1.9x), and it reports
-the DMA cycle-steal so the CPU coupling stays visible.
+It accounts for what eats the pipe before video sees any of it: audio
+(7.8 KB/s), the buffering condition, and it reports the DMA cycle-steal so the
+CPU coupling stays visible.
 
-At 4 Mbps it currently returns:
+At 4 Mbps it returns:
 
-| | lam | mean | peak | 00020 | 00146 | CPU |
-|---|---|---|---|---|---|---|
-| today (no rate control) | 25 | 194 KB/s | 368 KB/s | -1.22 dB | -4.21 dB | 53% |
-| with rate control wired | 10 | 305 KB/s | 305 KB/s | -0.52 dB | -2.98 dB | 51% |
+| sizing rule | lam | mean | 00020 | 00146 | CPU |
+|---|---|---|---|---|---|
+| **buffered (default, FINDINGS 21)** | **10** | 305 KB/s | -0.52 dB | -2.98 dB | 51% |
+| `--size-for-peak` (FINDINGS 18, superseded) | 25 | 194 KB/s | -1.22 dB | -4.21 dB | 46% |
 
-**Rate control is worth a full step on the quality ladder** — it is not a
-tidiness feature, it is the difference between sizing for the peak and sizing
-for the mean. That is the strongest argument yet for wiring up `ratectl.py`.
+The default is the buffered test: cumulative demand vs cumulative supply.
+Ring-buffer simulation gives **zero required prefill** for every measured scene,
+so `lam=10` ships without rate control. `--size-for-peak` reproduces the earlier
+pessimistic sizing and is kept only as a bound.
+
+**Rate control is therefore insurance, not a fix.** Its value is a deterministic
+ceiling over the 220 streams not yet measured — see the survey caveat below.
 
 ## What would change the design
 
@@ -127,7 +131,11 @@ for the mean. That is the strongest argument yet for wiring up `ratectl.py`.
   collapses toward today's `sasi`, and the two profiles stop being meaningfully
   different. At that point reconsider 10 fps, or a narrower active area.
 - **If sustained is much above** (>=8 Mbps / 976 KB/s): `lam=0` fits with
-  margin and the port ships **pixel-exact** video on SCSI.
+  margin and the port ships **pixel-exact** video on SCSI. At the current
+  4 Mbps figure this is NOT available — `lam=0` needs 92-97% of the pipe.
+- **If the full-disc survey finds a sustained action sequence hotter than
+  00146** (313 KB/s mean, the worst of 4 clips sampled): that is the scenario
+  rate control exists for, and the reason to wire it up before the survey run.
 - **If DMA cannot be used** and transfers fall back to PIO, the CPU cost rises
   from ~15% to something far larger and CPU becomes the binding constraint.
   This is the single worst outcome and is worth checking early in Tier 1.