docs: record capture-domain bottleneck + future optimization levers

Board V1 ships as-is (capture closes full-speed on 4/8 seeds). Documents,
for a possible future push toward more capture margin (e.g. 64 MHz), that
the binding path is now the tx_fifo exi->capture Gray-code CDC pointer
loop (~6.4ns logic + ~10.7ns routing = 17.1ns / 58.4MHz), and the two
measured levers: a lightweight 2-deep ping-pong TX CDC (RTL, pinout-
independent, est. 67-80MHz - the reliable one) and EXI/W5100 pin
co-location on one die edge (respin, routing-half only, ~63MHz seen).
Both investigated but NOT applied.

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

CLAUDE.md

@@ -103,6 +103,35 @@ from 24.3 → 19.6 ns and lifting capture to 4/8 passing (best 58.4) EVEN with t
 shell integrated. **Do not re-introduce any `tx_fifo.r_rdy` dependence into
 `r_en` or the flush deassert** — see the comment in `exi_capture.py`.
 
+**Remaining capture bottleneck + future levers (measured 2026-08, best seed):**
+After the flush fix the binding capture path is the **`tx_fifo` (exi→capture)
+consume-pointer Gray-code CDC loop**, triggered by `spi.tx_load`:
+`tx_load → consume_r_gry → consume_r_bin (gray→bin) → increment →
+consume_r_gry (bin→gray) → setup`. On the board's V1 pinout it is ~6.4 ns
+LOGIC + ~10.7 ns ROUTING = 17.1 ns (58.4 MHz). Two independent levers, if more
+capture margin (e.g. a 64 MHz target) is ever wanted — NOT done, board V1 ships
+as-is at 4/8-seed full speed:
+- **Lightweight TX CDC (RTL, pinout-independent — the reliable lever):** the TX
+  path carries one response byte per SPI byte-time (~3.4 MHz) with huge slack,
+  yet pays for a full Gray-code multi-bit-pointer AsyncFIFO. Replacing `tx_fifo`
+  with a **2-deep ping-pong CDC** (two byte regs + 1-bit toggle handshakes,
+  `ready = write_sync ^ read_toggle`) makes consume a single toggle flip + mux,
+  cutting the ~6.4 ns pointer logic to ~2–3 ns AND shrinking the cell count
+  (tighter routing). Est. ~67–80 MHz — comfortably past 64. CRITICAL PATH,
+  handle with care: `tx_fifo` feeds MISO live and the register file prefetches
+  into it (≤4 in flight for DMA reads), so the ping-pong needs adequate depth +
+  full ExiCapture/BBATop CDC re-verification (a bad handshake mis-enumerates).
+- **Pin co-location (respin-only, routing-half — ~+5 MHz):** on V1 the EXI pins
+  are on the BOTTOM die edge (y0) and the W5100 parallel bus is on the TOP
+  (y31), so the capture and exi/sync domains anchor to opposite edges and the
+  CDC FIFO spans the die vertically (that IS the ~10.7 ns routing). Putting the
+  EXI + W5100 pins on the SAME edge co-locates the domains: a confounded test
+  (EXI moved to top) hit 63.2 MHz best (routing 10.7→9.5 ns; logic unchanged).
+  Only moves the routing half and needs a full re-pinout (SG48 lacks free
+  top-edge pins for a clean version) — so it is a V2 consideration, not a fix.
+  (A simple 2-pin LED↔MISO/MOSI swap does NOT help — the EXI pins are already
+  clustered on the bottom edge; that swap tested WORSE, 58.4→48.8.)
+
 There is little margin: assume added logic in (or near) the capture domain may
 break capture timing until a sweep proves otherwise. The earlier "~70 MHz, both PASS" figure in this
 file was wrong — it came from a sweep that silently never ran (see the