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/FINDINGS.md

@@ -103,6 +103,10 @@ regression references; 03 and 04 are the correct ones.
 
 ## 5. Storage interface — the SASI/SCSI split
 
+> **SUPERSEDED IN PART.** The claim below that DMA means streaming "costs
+> essentially no CPU" is **wrong** — see 19. The bandwidth figures here are
+> folklore; the working figure is now **4 Mbps = 488 KB/s** (21).
+
 [Yasuma, X68030 internal SCSI controller]
 
 - Interface: **SCSI-1**, 50-pin, 5 MB/s bus spec
@@ -196,6 +200,11 @@ Caveat: all of the above is from README/repo-tree summaries, not their source.
 
 ## 8. CORRECTION to session 1: halving the framerate does NOT halve the bitrate
 
+> **PARTLY SUPERSEDED.** The framerate correction stands. The
+> "changed-spans + deflate = 247 KB/s" figure is a **compression upper bound,
+> not a shippable design** — deflate decode does not fit the 68000's frame
+> budget. See 17.2.
+
 Session 1 measured 365 KB/s for naive delta+RLE at 24 fps and wrote
 "(~183 KB/s at 12fps)". **That extrapolation is wrong.** Decimating to 12 fps
 roughly doubles the per-frame delta, so the *rate* stays nearly flat.
@@ -267,6 +276,9 @@ should: under a hard ceiling, detail blocks are the first thing sacrificed.
 
 ## 11. Codebook size sweep (flat 4x4, for reference)
 
+> **SUPERSEDED.** The k=1024 result below is an artifact of a rate model that
+> charged 1 byte for a 10-bit index. k=256 ships. See 14.
+
 | block | k | PSNR | loss | key B | changed% | KB/s @12 | codebook RAM |
 |---|---|---|---|---|---|---|---|
 | 4x4 | 256 | 30.46 | 8.39 | 3072 | 52.7 | 28.5 | 8K |
@@ -373,6 +385,12 @@ transcription errors before any of it is committed to 68000 tables.
 
 ## 17. The profiles were set far too low — and entropy coding is a CPU trap
 
+> **PARTLY SUPERSEDED.** 17.1's diagnosis (the profiles were not derived from
+> hardware) and 17.2's CPU analysis both stand. But 17 reasoned against a
+> misread bandwidth of 4 MB/s; the correct figure is **4 Mbps = 488 KB/s**, so
+> the "ship pixel-exact if SCSI sustains >=800 KB/s" conclusion in 17.5 is
+> **not available**. See 18 and 21.
+
 Prompted by the user asking why the SCSI profile was only 75 KB/s. It should not
 have been. Two separate errors, one of them serious.
 
@@ -453,6 +471,12 @@ SCSI is now waiting on one measurement.
 
 ## 18. Peak-to-mean burstiness — the mean was hiding the problem
 
+> **SUPERSEDED — DO NOT ACT ON THIS SECTION.** The peak-vs-sustained comparison
+> below is the **wrong test**. With a ring buffer the correct test is cumulative
+> demand vs cumulative supply, and both profiles pass it with **zero required
+> prefill**. `scsi` at lam=10 ships. See 21. The per-frame peak numbers
+> themselves are still valid data; only the conclusion drawn from them is wrong.
+
 Prompted by the user clarifying that the bandwidth figure is **4 Mbps = 488 KB/s**,
 not 4 MB/s. That is ~8x tighter than what 17 was reasoning against, and it
 changes the answer.