Decode NCRB and the registers with non-zero hardware defaults

Compat TODO items 3 and 4.  Every register libogc2 writes now stores writes and
reads back, with the documented hardware reset defaults: NCRB (0x01), BP
(0x0A/0B), TLBP (0x0C/0D), RXINTT (0x14/15), RHBP (0x1A/1B), NWAYC (0x30,
default 0x84), GCA (0x32), MISC (0x3D, default 0x3C), MISC2 (0x50).  BP and
RHBP reset to OUR layout (page 1, page 15) so a driver reading them back
without writing sees something consistent with where the ring actually is.

Previously all of these read 0x00 and dropped writes, so a driver doing
read-modify-write or sanity-checking a default saw zero -- and libogc2 does
read NWAYC before writing it.

Deliberately still reading 0x00: LTPS, LRPS, TWP, TRP, TXFIFOCNT.  Those are
STATUS registers, not configuration, so storing what was written to them would
be a lie rather than a default.  Drivers read LRPS/LTPS only on error bits and
0x00 reads as "no error", which is truthful for a device that does not detect
them.

NCRB, BP and RHBP are also exported as BBARegisterFile.ncrb/.bp/.rhbp for the
RX-filtering work (item 1) and the ring-geometry check (item 2).  Nothing
consumes them yet -- the decode lands first so the behaviour that uses it is a
separate, testable change.

T15 checks the defaults, replays libogc2's twelve init writes in its order and
reads every one back, and asserts the NCRB export is 0x52 with PR=0, PM=0,
AB=1 -- i.e. that the real BBA delivers own-MAC + broadcast only, which is the
fact item 1 has to act on.  Mutation-tested: dropping NWAYC's 0x84 default
fails it, as does dropping NCRB writes.

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

docs/bba_compat_todo.md

@@ -73,7 +73,9 @@ console) rather than corrupt silently.
 
 ## 3. `NCRB` (0x01) is not decoded at all
 
-**Status: OPEN.** Bits, from libogc2:
+**Status: ✅ DECODED 2026-10-10** — stored, readable, and exported as
+`BBARegisterFile.ncrb`. Nothing consumes the bits yet; that is item 1.
+Bits, from libogc2:
 
 | bit | name | meaning |
 |---|---|---|
@@ -87,10 +89,30 @@ console) rather than corrupt silently.
 We interrupt per frame where libogc2 asks for every 2 packets, which is benign
 (more interrupts than requested). `PR`/`PM`/`AB` feed item 1.
 
+`bba_register_file` **T15** asserts the export is `0x52` with `PR=0`, `PM=0`,
+`AB=1` — i.e. the real BBA would deliver own-MAC + broadcast only — which is
+the fact item 1 has to act on.
+
 ## 4. Registers that read `0x00` but have non-zero hardware defaults
 
-**Status: OPEN.** A driver doing read-modify-write, or sanity-checking a
-default, sees zero. libogc2 *does* read `NWAYC` (0x30) before writing it.
+**Status: ✅ DONE 2026-10-10** for every register libogc2 writes. They now
+store writes and read back, with the documented hardware defaults at reset.
+`bba_register_file` **T15** checks the defaults, replays libogc2's twelve
+init writes and reads every one back; mutation-tested (dropping `NWAYC`'s
+`0x84` default fails it, as does dropping `NCRB` writes).
+
+Still reading `0x00`, deliberately: `LTPS` (0x04), `LRPS` (0x05), `TWP`
+(0x0E/0F), `TRP` (0x12/13) and `TXFIFOCNT` (0x3E/3F). These are **status**
+registers, not configuration — a driver reads them to learn what the device
+did, so storing what was written to them would be a lie rather than a default.
+Drivers read `LRPS`/`LTPS` only on error bits, and `0x00` reads as "no error",
+which is the truthful answer for a device that does not detect those errors.
+`TWP`/`TRP`/`TXFIFOCNT` would need the TX engine to actually report its page
+pointers and FIFO depth; worth doing if a driver is ever seen to poll them.
+
+The original problem for reference — a driver doing read-modify-write, or
+sanity-checking a default, saw zero. libogc2 *does* read `NWAYC` (0x30) before
+writing it.
 
 | reg | name | hardware default |
 |---|---|---|