Price the transport against the frame, and find dual address cannot fit

FINDINGS 59.7. tools/analysis/15_bus_occupancy.py has always answered "what does
each W cost" and never "what can the frame afford", and after 59.2 those are not
the same question. It now answers both, and takes an optional --kbps for the
auto-request rows -- the only rows whose cost depends on how long the record
takes to arrive.

On the gate container at 12 fps, decode term MEASURED: decode 68.5%, audio 1.25%,
HEADROOM 30.2% = 6.74 clocks per byte at a 37,403 B record. Against that, P4a
cut the transport from 391.7% of a frame to 40..95% -- four to ten times, the
largest movement in this project's cost model since the decoder was written --
and it still does not fit. A dual-address byte is a 4-clock read of the device
plus a 5-clock write to memory, so 9 clk/B is a FLOOR and the frame affords 6.74.
No GCR share goes under it and no delivery rate goes under it: a share decides
whether the channel sits at the floor or above it. At 460 KB/s max-rate totals
165.1% and LRAR at 50% totals 117.4%, and a 50% share tops out at 543 KB/s, above
which the channel is the bottleneck and the rate falls back to exactly that floor.

So 59.2's three bounds arrive in the budget as one sentence: the configurations
this machine can run are the ones the frame cannot afford, and the one it can
afford -- single address, 5 clk/B, 92.2% total, 7.8% spare -- needs the device to
ACK the DMAC, which needs a request line MAME does not connect and the slot
pinout does have at B36/B37.

ROADMAP re-ranks accordingly. B3 stops being a constant to look up and becomes
DOES THE CARD DRIVE #EXREQ, ahead of B1: B1 sets how much headroom the player
has, B3 decides whether there is any. New E7 carries the other branch -- if the
answer is no, the container must reach 27,995 B a frame, 328 KB/s of payload,
against 438 now. The dependency diagram is redrawn around that fork.

The scope is stated rather than buried: this is the GATE container, deliberately
the heaviest thing the encoder emits, and the lighter cpufit family was NOT
priced -- 15_bus_occupancy.py refuses it, correctly, because the C68K measurement
it cross-checks against belongs to the gate container. E7 therefore begins with a
harness re-run, and until then "34% too big" is a statement about the fixture and
not about the project.

check.sh ALL GREEN before and after.

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

README.md

@@ -172,6 +172,23 @@ to land, and of the four bus shares the GCR can be programmed for — 50, 25,
 a frame. The GCR is a design lever nothing in this tree had named (FINDINGS
 59.3).
 
+**And what it all costs: the frame affords 6.74 clocks a byte, and a
+dual-address byte is 9.** Putting the transport on the channel cuts it from
+**391.7% of a 12 fps frame to 40..95%** — four to ten times, the largest
+movement in this project's cost model since the decoder was written — and **it
+still does not fit.** After the measured decode (68.5%) and the audio DMA
+(1.25%), 30.2% of the frame is left, which at this container's 37,403 B record
+is 6.74 clocks a byte; a dual-address byte is a 4-clock read of the device plus
+a 5-clock write to memory, so **9 is a floor no bus share and no delivery rate
+goes under**. Single address is 5 and fits at 92.2% with room to spare — and it
+needs the device to ACK the DMAC, which needs a request line MAME does not
+connect and the slot pinout does have. So the project's live question is now a
+fact about a board: **does a real CZ-6BS1 drive `#EXREQ`?** If it does, the
+design fits. If it does not, the container has to come down from 438 KB/s of
+payload to **328** — which is an encoder target, entirely inside this project,
+and measured against the heaviest container the encoder emits rather than
+against a shipping one (FINDINGS 59.7).
+
 **A record is not a sector, and the cheapest fix is a re-encode.** 117 of 120
 records start part way into a 512 B block, and reading whole blocks into the
 ring corrupts the neighbouring records rather than merely wasting bytes — the