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

README.md

@@ -1,6 +1,6 @@
 # Dragon's Lair — Sharp X68000 port
 
-Porting Dragon's Lair to a stock X68000 (68000 @ 10MHz, 2MB, SASI/SCSI).
+Porting Dragon's Lair to a stock X68000 (68000 @ 10MHz, 2MB, SCSI).
 
 This is fundamentally a **video codec problem**, not a game-logic problem: the
 game logic is a scene table with branching input windows; the difficulty is
@@ -55,10 +55,13 @@ tools/bench/     MAME Lua injection harness + 68000 benchmark sources.
                  `prep_dlx.py`/`decode.lua`/`verify_decode.py` load, time and
                  verify `src/player/decode.s`; the verify pass is in check.sh.
 tools/vasm/      vasm m68k assembler (built from source)
-tools/encoder/   hybrid VQ encoder + DLX1 container writer (working).
+tools/encoder/   hybrid VQ encoder + DLX2 container writer (working).
+                 DLX2 4-byte-aligns every frame record: an odd `move.l` is an
+                 ADDRESS ERROR on a 68000, not a slow read (FINDINGS 28.3).
                  dlx.py is the reference DECODER -- ground truth for the 68000.
-src/player/      decode.s: the 68000 DLX1 decoder. Pixel-exact, and 31% of
-                 frames over the 12fps CPU budget. See FINDINGS 28.
+src/player/      decode.s: the 68000 DLX decoder. Pixel-exact; 1 frame of 120
+                 over the 12fps CPU budget once the mode decision prices
+                 cycles. See FINDINGS 28 and 31.
 assets/          extracted frames/audio (gitignored)
 ```
 
@@ -66,18 +69,24 @@ assets/          extracted frames/audio (gitignored)
 
 ```
 python3 tools/encoder/extract.py 00020 /tmp/fr 12 crop
-python3 tools/encoder/encode.py  /tmp/fr out.dlx --profile sasi --preview p.png
+python3 tools/encoder/encode.py  /tmp/fr out.dlx --profile scsi --preview p.png
 ```
 
-Two quality profiles ship from one codec and one decoder — `sasi` (110 KB/s) and
-`scsi` (280 KB/s) are two points on the same rate-distortion curve. Both are
-**ceilings**: lam is bisected per frame under a leaky bucket, so the profile's
-`lam` is a quality floor rather than a setting (`--fixed-lam` opts out).
+**One profile: `scsi`, 280 KB/s.** The 110 KB/s `sasi` profile was dropped in
+session 9 on capacity, not bandwidth — a SASI volume is limited to 40 MB, and
+the game's 22.8 minutes of footage is 146 MiB even at that rate (FINDINGS 32).
+The rate point may return under another name once the delivery medium is
+settled, because a 1x CD-ROM sustains ~150 KB/s and CD-ROM is the only period
+medium with the capacity.
+
+The profile bitrate is a **ceiling**: lam is bisected per frame under a leaky
+bucket, so the profile's `lam` is a quality floor rather than a setting
+(`--fixed-lam` opts out).
 
 There are **two** ceilings, on two different axes. The second is the 68000's
 decode budget: `mu` is bisected per frame against 833,333 cycles so the frame
 also *decodes* in time, which takes the worst sustained window from 37 frames
-over budget to 1 for 0.26 dB (FINDINGS 31). It is on by default; `--no-cpu-fit`
+over budget to 1 for 0.62 dB at `scsi` (FINDINGS 31). It is on by default; `--no-cpu-fit`
 restores session 7 behaviour. Unlike bytes, cycles have no bucket — there is no
 double buffer to decode ahead into, so it is a hard per-frame ceiling. The codec is
 a Cinepak-style hybrid: each 4x4 block is coded as SKIP, one 4x4 codeword, four