Put the ring on the 68000, and find the disc stops whenever the player is not asking

ROADMAP P5. The loader moved in session 21 and the frame clock in 22; the ring
producer was the last policy living outside the machine. src/player/ring.i does
`aligned` placement, the descriptor ring, a prefill, 51.2's slack rule and a
seek, and the host keeps only the transport.

It needed a container change. `aligned` asks whether the next record fits
before the end of the ring -- a length asked BEFORE the record is fetched -- and
every reader in this tree answered that by walking the frame stream, which is
exactly what a player streaming off a disc cannot do. DLX4 carries nframes u16
record lengths in the scene header. Frame payloads are byte-identical to the
DLX3 encode, so no fitted constant moves; the scene header goes 5,920 to 6,164 B.

The producer reproduces the host's tiling exactly: 18 wraps, 14.7 KB mean hole,
pixel-exact, a third independent implementation of the same policy.

What it exposed is bigger than the item. A channel only moves bytes while it has
a request and only the CPU can issue one, so the disc stands still between
records by an amount the PLAYER sets, not the medium -- and no host-filled run
could see it. At 488 KB/s in a 256 KB ring a one-deep request queue gives away
6.8% of the pipe and underruns 59 of 120 frames; two-deep gives away 3.4% and
underruns none. The container's whole surplus over the wire is 8.7%, so the
player's own loop was spending most of the slack a branch point saves up.
Prefill is the weaker lever: six records of it still leaves 24 underruns.

Three silent bugs are recorded in FINDINGS 55.7 -- all produced wrong pixels or
a desync rather than a fault -- plus a rig one: MAME renders a screen line by
line, so snapshotting the frame the decoder finished in captures a tear that
reads exactly like a decoder bug.

check.sh gains the machine-owned ring and a seek with the decode after it.
decode.bin is unchanged at 1,296 B and a host-filled run executes none of the
new code, so every FINDINGS 49/51 figure stands. ALL GREEN before and after.

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

README.md

@@ -117,6 +117,15 @@ of seek slack those bytes lengthen the refill climb by 138 ms at 488 KB/s and by
 **1.099 s at 451.4 KB/s**, because the surplus they are divided by goes to zero
 (FINDINGS 53).
 
+**The 68000 fills its own ring now, and the player's request loop costs more
+than the medium does.** `src/player/ring.i` places records, prefills, keeps the
+slack rule and seeks, out of a per-record index the container carries (DLX4).
+The channel only moves bytes while it has a request and only the CPU can issue
+one, so the disc **stands still between records** by an amount the player sets:
+at 488 KB/s a one-deep request queue gives away **6.8% of the pipe and underruns
+59 of 120 frames**, a two-deep one gives away 3.4% and underruns none — on a
+container whose whole surplus over the wire is 8.7% (FINDINGS 55).
+
 **Current encode:** 496.7 KB/s at 29.19 dB, 1 frame of 120 over the 12fps
 budget, and that one is frame 0, the intra frame, late on purpose.
 
@@ -317,6 +326,9 @@ tools/encoder/   hybrid VQ encoder and DLX3 container writer.
                  DLX2 4-byte-aligns every frame record, because an odd move.l
                  is an ADDRESS ERROR on a 68000, not a slow read.
                  dlx.py is the reference DECODER, ground truth for the 68000.
+                 24 models the ring with the 68000 owning it: the request
+                 queue, the poll-only-when-not-decoding rule and 54.4's frame
+                 cadence, and reports the pipe the player's own loop gives away.
 src/player/      decode.s is the 68000 DLX3 decoder with a preloaded-stream
                  front-end. stream.s is the same decoder behind a bounded ring.
                  load.i is the LOAD-time half: codebook expansion and palette
@@ -324,6 +336,11 @@ src/player/      decode.s is the 68000 DLX3 decoder with a preloaded-stream
                  its rig front-end. Its three scratch tables describe the
                  machine rather than the scene, so they are a separate entry
                  point a player calls once at boot.
+                 ring.i is the RING PRODUCER: `aligned` placement, the
+                 descriptor ring, the prefill policy, 51.2's slack rule as
+                 arithmetic (ring_may_seek) and a seek. It reads the DLX4 record
+                 index because a player cannot learn a record's length by
+                 walking a stream it has not fetched.
                  Both include frame.i (the block loop and span chain) and
                  geom.i (the constants), so there is exactly ONE copy of the
                  bytes every cycle constant is fitted to. The span pass is