Map the full-frame micro-code structure: double-buffered primitives

frame_primitives.py decodes every coeff-copy word over the draw: 1051 SEND,
334 SENDE, 384 TILE, 327 GOTO, 231 STOP across 105 tiles -- but only 2 distinct
SEND payload addresses (0x08015xxx/0x08017xxx). That's double-buffering: the
firmware compiles each primitive into an alternating coeff block and SENDs it,
so the content changes over time while the addresses don't. A from-scratch full
frame must snapshot each primitive's payload at its SEND, then run all of them.
Readout §05 + notes updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

emulator/firmware-decomp/render-readout.html

@@ -354,8 +354,10 @@
     carry no stored vertices. But that stream is now largely decoded: the command lists read cleanly,
     the <span class="mono">SENDE</span> z-sweep resolves into a regular 4-word instruction, and its
     coefficients are the same ones driving this depth buffer — the array's inputs are
-    <b>cross-validated against the hardware's own compiled stream</b>. What remains is numeric
-    reconstruction across every region, not reversing an opaque binary.</p>
+    <b>cross-validated against the hardware's own compiled stream</b>. The full frame, we now know,
+    cycles its primitives through <b>two double-buffered coefficient blocks</b> — 1051 SENDs, 384
+    TILE ops across <b>105 tiles</b> — so what remains is capturing each primitive as its SEND fires
+    and running them all, not reversing an opaque binary.</p>
   </section>
 
   <section>