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

docs/STATUS.md

@@ -57,6 +57,33 @@ writes a contiguous run and cannot drop the 300 B in front of a record, so
 "sector-aligned records should join the bundle" has become "the transport will
 not run without them".
 
+**6. WHAT IT ALL COSTS, and this is the part that re-ranks the roadmap.**
+`15_bus_occupancy.py` now answers "what can the frame afford" as well as "what
+does each `W` cost". On the gate container at 12 fps, with the decode term
+MEASURED: decode 68.5%, audio 1.25%, **headroom 30.2% = 6.74 clocks per byte**
+at a 37,403 B record.
+
+| transport | clk/B | video | total |
+|---|---|---|---|
+| PIO, measured (58.2) | 87.28 | 391.7% | **461.5%** |
+| dual address, held — **the floor** | 9 | 40.4% | **110.2%** |
+| single address, held | 5 | 22.4% | **92.2%** |
+
+**P4a cut the transport from 391.7% to 40..95%, four to ten times — and it still
+does not fit.** A dual-address byte is 4 clocks of device read plus 5 of memory
+write, so **9 is a floor and the frame affords 6.74**; no GCR share and no
+delivery rate goes under it. At 460 KB/s max-rate totals 165.1% and LRAR at 50%
+totals 117.4%. So the fit turns on **B3, which has stopped being a constant to
+look up: does a real CZ-6BS1 drive `#EXREQ`?** If yes, single address fits at
+92.2% with 7.8% spare. If no, the container must reach **328 KB/s of payload**
+(new ROADMAP E7), against 438 now.
+
+**The scope matters and is stated in 59.7:** this is the GATE container, the
+heaviest thing the encoder emits. The lighter `cpufit` family was NOT priced —
+the tool refuses it, correctly, because the C68K measurement belongs to the gate
+container — so E7 begins with a harness re-run, and until then "34% too big" is
+about the fixture, not about the project.
+
 **ONE COLLISION, AND THE BEFORE-HALF OF `check.sh` CAUGHT IT.** `DM_USE` was
 first placed at `$18300`, which is `ring.i`'s `XF_SLOT` mailbox — `scsi.i`'s
 trace ends at `$182FF` and the next 160 bytes are the ring's. The ring rig's