Drop SASI on capacity, then find the budget never had the disk in it

USER DECISION: drop the `sasi` profile. Not on bandwidth -- on capacity. A SASI
volume is 40 MB, and the 22.8 min of unique scene footage on the source Blu-ray
(streams 00000-00201, measured, not recalled) is 146 MiB at the LOWEST rate this
codec makes -- more than the machine's whole 4-unit SASI space. `scsi` is the
only profile now. FINDINGS 32.

Then the user asked whether we were drawing the wrong conclusions about PIO vs
DMA, and we were, more broadly than the question implied. Every CPU figure in
FINDINGS 24-34 is scored against the full 833,333 cycles/frame with nothing
subtracted for moving the bitstream off disk. Debiting the HD63450 cycle-steal
at the long-standing 8 clk/word ESTIMATE, "1 frame of 120 misses" becomes 84 of
120, median 112.4%. PIO at the span rate is 99.8% of the machine. Spans buy
cycles by spending bandwidth and the bandwidth returns as steal, so 31.6's "fits
completely" becomes a worst frame of 114.3%. 10 fps absorbs it: median 93.7%,
1/120. FINDINGS 35. `11_cpu_budget.py` takes --io dma|pio|none, defaults to dma,
and warns if asked for none.

Also landed:
- item 1 done: the cost model checked against the 68000 on a cost-aware
  container, -3.07% to +0.01%, whole-window mean -1.22%. FINDINGS 34.
- item 4 done: the container carries its own 4-byte record alignment (DLX2).
  94/120 record starts were on odd addresses -- an address error, not a slow
  read -- now 0/120 for 16 B/s. Re-encoding reproduces 31.1 exactly. FINDINGS 33.
- a `scsi` window does not fit the 2 MB machine the rig emulates (2.84 MB of
  stream past a 0x200000 ceiling). The gate now verifies 80 of 120 frames and
  SAYS so, and fails loudly when the pass does not complete, instead of
  reporting a phantom 49,005-pixel diff. FINDINGS 36.

Three near-misses this session had one shape: an unobservable run nearly
produced a false finding. stdbuf -oL on any MAME job that prints progress -- a
file is block-buffered too, and a run that is merely finishing looks exactly
like one that is wedged.

check.sh ALL GREEN.

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

tools/bench/check.sh

@@ -57,17 +57,40 @@ echo "--- session 7: 68000 decoder is pixel-exact (FINDINGS 28) ---"
 # 68000 code, every block mode, full temporal recursion. A SKIP block is a claim
 # about the previous frame still being on screen, so the last frame is only
 # right if all 120 were.
-DLX=tmp/rc_fr_singe_sasi_rcprofile.dlx
-[ -f "$DLX" ] || python3 tools/encoder/encode.py tmp/fr_singe "$DLX" --profile sasi
+# The gate container is the CURRENT default encode: scsi (the only profile left
+# after session 9 dropped sasi on capacity, FINDINGS 32), cost-aware mode
+# decision on, DLX2 4-byte-aligned records. It is also the heavier stream --
+# 43% RAW against sasi's 10% -- so it exercises the decoder harder than the
+# session-7 container this gate used to run on.
+DLX=tmp/rc_fr_singe_scsi_cpufit.dlx
+[ -f "$DLX" ] || python3 tools/encoder/encode.py tmp/fr_singe "$DLX" --profile scsi
 python3 tools/bench/prep_dlx.py "$DLX" > tmp/prep_dlx.log
+# The rig loads the whole stream into a 2 MB machine, so a scsi window does not
+# fit and prep_dlx truncates it. Verify against exactly the prefix it emitted.
+NF=$(sed -n 's/.*nframes=\([0-9]*\),.*/\1/p' tmp/decode_meta.lua)
+grep -a "TRUNCATED" tmp/prep_dlx.log || true
 tools/vasm/vasmm68k_mot -Fbin -o tmp/decode.bin src/player/decode.s > /dev/null
 mkdir -p tmp/snap_decode
 rm -f tmp/snap_decode/x68000/*.png
-( cd tmp && DLX_VERIFY_ONLY=1 SDL_VIDEODRIVER=dummy timeout -k 5 300 mame x68000 \
+# stdbuf -oL: a FILE is block-buffered too, so without it a long MAME run is
+# unobservable until it exits and a run that is merely finishing looks exactly
+# like one that is wedged (FINDINGS 34.1).
+# -seconds_to_run must cover the WHOLE sequential pass. The scsi container is
+# 2.7x the payload of the session-7 one this gate used to run on, and at 20 s
+# the pass was truncated -- MAME exited mid-decode and verify_decode.py then
+# compared a partially drawn screen and reported 49,005 differing pixels, which
+# reads as a decoder bug and is not one.
+( cd tmp && DLX_VERIFY_ONLY=1 SDL_VIDEODRIVER=dummy stdbuf -oL timeout -k 5 300 mame x68000 \
     -bios ipl10 -ramsize 2M -video soft -window -sound none -nothrottle -plugins \
     -autoboot_script ../tools/bench/decode.lua \
-    -snapshot_directory ./snap_decode -snapview native -seconds_to_run 20 \
+    -snapshot_directory ./snap_decode -snapview native -seconds_to_run 45 \
     > decode_check.log 2>&1 )
-python3 tools/bench/verify_decode.py "$DLX"
+# A truncated run must fail as a truncated run. Without this the only symptom is
+# a pixel diff against a half-drawn frame.
+grep -q "snapshot taken" tmp/decode_check.log || {
+  echo "FAIL: the 68000 sequential pass did not complete -- no snapshot marker."
+  echo "      Raise -seconds_to_run; the pass needs the whole container decoded."
+  tail -5 tmp/decode_check.log; exit 1; }
+python3 tools/bench/verify_decode.py "$DLX" --nframes "$NF"
 
 echo "ALL GREEN"