Raise both quality profiles; rule out entropy coding on CPU grounds

The profiles shipped in e4062ed were set far too low. 45 KB/s (sasi) and
75 KB/s (scsi) are 12% and 7% of the respective folklore bus figures. They had
been read off the knee of the rate-distortion curve and then presented as
though bandwidth-derived, which they were not.

Raised to sasi 110 KB/s (lam=60) and scsi 280 KB/s (lam=10) -- 35% and 28%
utilisation. scsi is now within 0.52 dB of the palette ceiling on scene 00020.

Checking the CPU side, which nobody had done for the decode path, produces a
second and more important result. Against the 833k cycle/frame budget at 12fps:

  full-frame blit, every frame     319k   38%   affordable
  LZ4/LZSS decode ~30KB/frame      450k   54%
  deflate decode  ~30KB/frame     1800k  216%   infeasible

So raising the VQ bitrate is nearly free -- RAW, the mode that dominates at
high rate, is the cheapest mode to blit -- but entropy coding is not viable at
all. That demotes the "247 KB/s lossless changed-spans+deflate" figure from
FINDINGS 8 to a compression upper bound rather than a shippable design, and
removes entropy coding from the roadmap. VQ is the right architecture precisely
because its decode is a table copy.

Also confirms the architecture unifies: the hybrid at lam=0 lands within 3% of
the purpose-built lossless coder, so there is no separate lossless path.

Consequence for planning: the blocked disk benchmark is now critical-path, not
optional. If SCSI sustains >=800 KB/s the correct scsi profile is lam=0 --
pixel-exact video at ~450 KB/s and 38% CPU. Whether this port ships transparent
or lossy on SCSI is waiting on one measurement.

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

tools/encoder/ratectl.py

@@ -19,25 +19,38 @@ import vq_hybrid as H
 # see docs/FINDINGS.md 5 -- these are FOLKLORE-grade until the disk benchmark
 # is unblocked, so they are deliberately conservative fractions of the quoted
 # ceiling (audio, seeks and container overhead come out of the same pipe).
-# Calibrated against the CORRECTED rate-distortion measurement (FINDINGS 14).
+# Calibrated against the corrected rate-distortion curve (FINDINGS 14-15) AND
+# against the bus and CPU budgets (FINDINGS 17). Session 2 initially set these
+# far too low: 45 / 75 KB/s is 12% of the pessimistic SASI folklore figure and
+# 7% of the SCSI one. Nothing justified that -- the numbers were read off the
+# knee of the RD curve, not off the hardware.
 #
-# k=256 with 1-byte indices beats k=1024 with 2-byte indices at every matched
-# bitrate. The earlier "+2.4 dB for k=1024" was an artifact of a rate model that
-# charged 1 byte for a 10-bit index. 1-byte indices also mean the 68000 decoder
-# reads a plain move.b with no alignment case, and the codebook is 8 KB not 32 KB.
+# What actually bounds the high end:
+#   - Bus: unmeasured. ~300-500 KB/s SASI / ~1 MB/s SCSI, both FOLKLORE.
+#     This is the binding unknown and the reason the disk benchmark matters.
+#   - CPU: a FULL-frame blit is only 38% of the 12fps budget, and VQ decode is
+#     table copies (RAW, the mode that dominates at high rate, is the CHEAPEST
+#     to blit). So raising the bitrate is nearly free on CPU.
+#   - Entropy coding is NOT the way to buy headroom here: deflate decode is
+#     ~216% of the frame budget on a 68000 and even LZ4 is ~54%. See FINDINGS 17.
+#     The rates below are therefore RAW payload, no entropy coding.
 #
 # The two profiles are the SAME codec, decoder and bitstream -- only `lam` differs.
 PROFILES = {
-    "sasi": dict(kbps=45,  lam=300.0, k1=256, k4=256,
+    "sasi": dict(kbps=110, lam=60.0, k1=256, k4=256,
                  desc="stock 10MHz ACE/EXPERT, SASI",
-                 quality="34.8 dB on 00020 / 28.3 dB on 00146"),
-    "scsi": dict(kbps=75,  lam=100.0, k1=256, k4=256,
+                 quality="36.9 dB on 00020 / 29.6 dB on 00146",
+                 util="~105 KB/s = 35% of the pessimistic 300 KB/s SASI figure"),
+    "scsi": dict(kbps=280, lam=10.0, k1=256, k4=256,
                  desc="Super/XVI, or CZ-6BS1 board in a 10MHz machine",
-                 quality="35.9 dB on 00020 / 29.0 dB on 00146"),
+                 quality="39.4 dB on 00020 / 32.3 dB on 00146",
+                 util="~275 KB/s = 28% of the 1 MB/s SCSI folklore figure"),
 }
-# Not a shipping profile, but the curve continues: lam=25 is ~185 KB/s at ~38.7 dB
-# with 26% RAW blocks, and lam->0 is pixel-exact (0.00 dB loss). Entropy-coding
-# the payload (NOT YET IMPLEMENTED) should shift the whole curve ~1.4x left.
+# lam=0 is PIXEL-EXACT against the palettised frame (0.00 dB loss) at ~450 KB/s
+# of raw payload, and costs only 38% of the CPU budget. If the blocked disk
+# benchmark confirms SCSI sustains >=800 KB/s, the `scsi` profile should become
+# lam=0 and the port ships transparent video. That decision is waiting on a
+# measurement, not on a design choice.
 
 AUDIO_KBPS = 7.8          # MSM6258 ADPCM 15.6kHz mono -- comes out of the same budget