docs: tests/README — sniffer-attribution methodology + per-band sniffer assignment

[josephnef]

Summary

• Reframe --sniffer-iface from "optional encoding-distribution dump" to "third independent witness that attributes TX-vs-RX failure". New top-of-file Failure attribution via the sniffer section makes the 2×2 (sniffer-caught × RX-counted) decoder explicit so every cell goes from "did the pair work?" to "which side broke?".
• Document the per-band sniffer assignment used on the current test rig: AR9271 (ath9k_htc) for 2.4 GHz, RTL8832AU (8852au, lwfinger OOT) for 5 GHz (UNII-1/2/3). The kernel-6.18 patch set for the OOT driver lives in kaeru (lwfinger/rtl8852au — kernel 6.18 build patches) and is not duplicated here.
• Position VM mode as needed only for the cross-driver interop rows on chips whose host kernel driver doesn't build (notably RTL8814AU on 6.15+) — sniffer-equipped devourer-only regression hunts no longer need the kernel side at all.
• Update the --full-matrix example to thread --sniffer-iface through, and point at --no-baseline-abort for runs where the kernel side genuinely can't come up.
• Caveat: one host stall observed (2026-06-04) with RTL8832AU as 5 GHz sniffer under --full-matrix --channel 36 with three concurrent Realtek DUTs on the same xhci bus. Hard CPU stall, no oops/NMI. Retry was inconclusive (logs lost on tmp cleanup). Documented so the next person doesn't reproduce blind.

No code change; doc-only.

Validation context

Background matrix runs on master used to assemble this doc:

• ch6, AR9271 sniffer, VM mode — 23/24 cells pass. Only the known 8814 TX on-air gate fires (cells 2/4/6/8); sniffer-confirmed 0 frames flew despite 4500 submits. The sniffer-attribution row directly demonstrates why this fail is attributable to the chip's TX path and not to anything RX-side.
• ch36, no sniffer, VM mode — 16/24 cells pass; the failures match the documented per-band/per-pair shape (8814 dev-RX at 5 G, 8821↔8812 cross-receiver asymmetry).
• ch100, no sniffer, VM mode — 15/24 cells pass; the new failures over ch36 (cells 14, 16, 23, 24) trace to the documented 8812-receiver-side asymmetry at UNII-2/3, not a regression. Verified by re-testing the focused 8821↔8812 ch100 4-cell at 4b3e79a (PR fix: 8821AU ch100 chip wedge on second channel-set during init (issue #59) #70) where the d/k and d/d cells were already 0 hits when the original "ch100 chip-wedge fix" landed.

Test plan

• Read-through review — the new attribution section is the load-bearing part.
• sudo python3 tests/regress.py --full-matrix --channel 6 --sniffer-iface <AR9271 iface> --vm-name devourer-testrig --vm-ssh <user>@<vm-ip> reproduces the 23/24 + 8814-TX-gate signature against the README's stated expectation.

🤖 Generated with Claude Code