Fix the RX ring descriptor to the format libogc actually parses

The assembler wrote 00 00 len[11:8] len[7:0] with bytes 0 and 1 zero.  The real
format, read out of libogc's own BBA driver, is a PACKED 32-BIT LITTLE-ENDIAN
word: next_packet_ptr in bits 0-11, packet_len in bits 12-23, status in bits
24-31.  Under that driver our descriptor for a 342-byte frame decoded as a
12-byte frame with a next-pointer of 0 into the reserved page, so Swiss and
anything else built on libogc would have initialised perfectly and then
misparsed every received frame.

Found by disassembling /opt/devkitpro/libogc/lib/cube/libbba.a (gcif.o,
bba_interrupt) rather than by guessing:

  lwbrx   r9,0,r9              # 4 bytes as a little-endian word
  rlwinm  r4,r9,20,20,31       # packet_len = (word >> 12) & 0xFFF
  addi    r4,r4,-4             # payload = packet_len - 4
  cmpwi   r4,1540
  srwi    r9,r9,24             # status = word >> 24
  and.    r9,r9,r18            # r18 = 0x..84 -> errors are 0x80 | 0x04

and the low 12 bits are written straight back to RRP (0x0018/0x0019), which is
why next_packet_ptr has to be there at all -- it is the driver's read pointer.

The length semantics and addressing were already correct (descriptor at
page<<8, body at +4, length including the descriptor); only the packing was
wrong and next_packet_ptr was never written.

RXFrameAssembler now computes the next page BEFORE writing the descriptor
(CALC_NEXT, formerly ADVANCE_RWP, moved ahead of the backfill) and writes bytes
0-3 as WRITE_D0..WRITE_D3.

WRITE_D3 fixes a latent bug this exposed: WRITE_PLACEHOLDER issues four writes
but the first lands twice, so desc_base+3 was NEVER written.  That was harmless
while the length write covered byte 3.  As the status byte it would have been
whatever the previous frame left in that cell, and a stale 0x80 or 0x04 makes
the driver discard the frame.

Readers updated to decode identically: netboot (which also now takes RRP from
the descriptor's own next_packet_ptr, as libogc does, instead of recomputing
the page span) and t_dma, including its page map.  netboot's +0/+1 offset probe
is removed -- the underrun that shifted descriptors is fixed and confirmed on
console, and under a packed format a +1 read is not a shifted descriptor but
garbage.

The assembler's testbench now decodes with libogc_decode(), reproducing the
instruction sequence above, so the tests check the DRIVER'S algorithm rather
than our own packing.  Every module testbench and bba_top at EXI_HALF=1/2/8
pass.

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

docs/gc_bba_fpga_design.md

@@ -553,14 +553,28 @@ Each page is 256 bytes. A received frame may span multiple pages.
 
 **Frame descriptor (first 4 bytes of first page):**
 
+A **packed 32-bit little-endian word**, not a byte-wise layout:
+
 ```
-Byte 0: LRPS value (Last Received Packet Status — set to 0x00 or actual status)
-Byte 1: 0x00
-Byte 2: frame_length[15:8]  (big-endian, includes descriptor bytes)
-Byte 3: frame_length[7:0]
-Bytes 4+: raw ethernet frame data (DA, SA, EtherType, payload, FCS)
+bits  0–11 : next_packet_ptr  — the PAGE at which the NEXT frame starts
+bits 12–23 : packet_len       — total bytes, INCLUDING these 4
+bits 24–31 : status           — 0x80 and 0x04 are errors; 0x00 means good
+
+Byte 0: next_packet_ptr[7:0]
+Byte 1: packet_len[3:0] << 4 | next_packet_ptr[11:8]
+Byte 2: packet_len[11:4]
+Byte 3: status
+Bytes 4+: raw ethernet frame data (DA, SA, EtherType, payload)
 ```
 
+⚠️ Read out of libogc's own BBA driver (`libbba.a`, `gcif.o`,
+`bba_interrupt`) — `lwbrx` loads the four bytes as a little-endian word,
+`rlwinm r4,r9,20,20,31` takes `packet_len = (word >> 12) & 0xFFF`, `srwi
+r9,r9,24` takes the status, and the low 12 bits are written straight back to
+`RRP`. This spec previously said `00 00 len_hi len_lo`, which that driver
+decodes as a 12-byte frame with a next-pointer of 0 for a 342-byte frame. Do
+not "simplify" it back to a plain big-endian length.
+
 **Flow:**
 
 1. Wait for `W5500SPIMaster` to signal frame available (`rx_sof` pulse).