Put the frame in a container with no decoder, and find the palette is not free

ROADMAP K2. DLXP1: a 49,664 B record that is 97 sectors exactly, no index and
no length word, because a packed record's length is geometry rather than
content. 582.0 KB/s, which is what FINDINGS 61.9 predicted to the tenth, and it
encodes in 3.3 s because there is no k-means in it.

px68k's own x68k/gvram.c renders the container's bytes index-exact with the
harness computing no interleave -- the only test that can catch an encoder whose
byte order is wrong, since a container round-trips against its own inverse
either way. Both negative controls fail as they must.

The picture is re-derived against this project's builder rather than PIL's
(34.05 dB against 61.9's 34.08) and the GGGGGRRRRRBBBBBI word is charged for the
first time in this tree: 0.53 dB, on every row, so it moves no comparison.

What the control found is the finding. A packed container on a SCENE palette
lands exactly on the codec's ceiling, so the whole +2.31 dB is the per-frame
palette and nothing else -- and 231 of 256 entries change every frame, which
makes a mismatched paint 12.8 dB worse than the correct pairing, on screen for
roughly half of every frame slot if buffer mode does not blank. So B2 now
decides which packed CONTAINER ships, not only which player. The fallback is
already a flag: --scene-palette --no-palette is 30.79 dB, zero churn, 576.0 KB/s
and still +2.07 dB on the shipping codec.

62.5 is priced and is a wash: palette first 20.32 dB, palette last 20.33.

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

tools/bench/dlxload.py

@@ -36,11 +36,18 @@ def pack_palette(d):
     which is the point: the verifier and the loader must agree or a colour bug
     reads as a decoder bug.
 
-    Returns (palette bytes 256x2 big-endian, index of the darkest entry).  The
-    encoder does not yet reserve a black entry (docs/STATUS.md, encoder gaps),
-    so the letterbox gets the closest thing to black the palette has.
+    Returns (palette bytes 256x2 big-endian, index of the darkest entry, and the
+    RGB888 the hardware actually RENDERS from those words).  The encoder does not
+    reserve a black entry in the CODEC container (docs/STATUS.md, encoder gaps),
+    so the letterbox gets the closest thing to black the palette has; the PACKED
+    container does reserve one (tools/encoder/dlxp.py, index 255).
+
+    `d` is a DLX container OR a bare (256,3) uint8 palette.  The packed path has
+    no codebooks and so no DLX object to carry a palette on, and this had to stay
+    the ONE copy of the GRB555+I maths -- the verifier, the loader and now the
+    packed encoder all have to agree or a colour bug reads as a decoder bug.
     """
-    pal = d.pal.astype(int)
+    pal = (d if isinstance(d, np.ndarray) else d.pal).astype(int)
     p6 = lambda v: ((v << 2) | (v >> 4)) & 0xFF
     f = pal >> 3
     render = lambda I: p6((f << 1) | I[:, None])