netboot: stop with the summary before booting Swiss

The transfer completes on hardware -- 293/293 blocks, 299908 bytes in 15.7 s --
but roughly a third of blocks needed a retry, and the numbers that say WHY are
printed by the GC and then scrolled away when Swiss boots.  So the one side
that knows whether an ACK failed to transmit or was lost on the wire could not
be read.

netboot now stops after writing the SD card and waits for a button press, and
the summary carries the counters that separate the cases:

    desc@+0=N +1=M  bad=N  lapped=N  txto=N

txto is the discriminator: it counts ACKs where TI never set, meaning the
frame never reached the W5100.  High txto alongside the host's retries points
at the TX path; txto near zero points at frames sent but lost.

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

gc_bba_test/README.md

@@ -163,7 +163,24 @@ one block per round trip, so block size sets the speed.
 
 A missing ACK is not fatal: the host retransmits, and the GC re-ACKs a
 duplicate block rather than ignoring it, so a lost ACK recovers in one
-timeout. `txto=N` in the status line counts ACKs where TI never set.
+timeout.
+
+**The GC stops with its summary before booting Swiss** — press a button to
+continue. Those counters are the only place the *reason* for a retry shows up:
+
+```
+desc@+0=N +1=M  bad=N  lapped=N  txto=N
+```
+
+- `txto` — ACKs where TI never set, i.e. the frame never reached the W5100.
+  High `txto` with many host-side retries means the TX path is the problem.
+- `txto` near zero with many retries means ACKs were sent but lost on the wire
+  or at the host.
+- `desc@+1` — frames whose ring descriptor landed at page offset +1 instead of
+  +0. Still unexplained; the reader handles both.
+
+Measured 2026-10-09: 299908 bytes in 293 blocks took 15.7 s with roughly a
+third of blocks retried — the retries, not the data, dominate the time.
 
 ### Stop-and-wait is load-bearing