RTL8733B: qualify or remove the experimental 5/10 MHz narrowband path (narrowband_ok is false)

[josephnef]

AdapterCaps::narrowband_ok is false on the RTL8733B backend merged in #388, despite the 5/10 MHz register sequence being implemented and reading back on hardware. This issue is the evidence path to flipping it — or to deleting the code if it cannot be qualified.

Blocked on #390 (SDR characterization) and on the BL-M8733BU2 board arriving; a narrowband claim without occupied-bandwidth proof is exactly the kind of unvalidated capability this project refuses to advertise.

Current state

docs/rtl8733b.md, "Narrowband status": the port follows the later workaround in rtl8733bu-20230626 — program the RF as 20 MHz, then apply the small-bandwidth BB clock fields after the RF writes. Both 5 and 10 MHz register transitions read back on the tested f72b device. Two reasons that is not enough:

• The vendor's published capability mask is 20/40 MHz. Narrowband here is a workaround, not a supported mode.
• The workaround's own description mentions a no-RF-output failure without its final writes. Register readback cannot distinguish "narrowband is airing" from "nothing is airing" — which is precisely the failure mode this chip's vendor documented.

That second point is the whole reason this is SDR-gated rather than delivery-gated.

Work items

1. Occupied bandwidth on an SDR at 5 and 10 MHz, both bands, confirming the emission actually narrows rather than the transmitter going quiet. This is the single measurement that resolves the vendor's documented failure mode.
2. Narrowband TX decoded by an independent narrowband peer. The other generations' narrowband is bench-characterized against a second devourer adapter tuned to the same width — do the same here (docs/narrowband.md has the established method). A witness locked to 20 MHz proves nothing about a 5 MHz emission.
3. Narrowband RX: ambient or peer-generated 5/10 MHz frames decoded by the RTL8733B, not just register state.
4. 5 MHz at 5 GHz specifically. On Jaguar2 this is CFO-limited; assume nothing about this die until measured, and be prepared to advertise 10 MHz only.
5. FastSetBandwidth parity if narrowband ships: tests/fast_bw_parity.sh is the register full-vs-fast check the other generations pass.

Decision point

Three honest outcomes, all acceptable:

• Qualified → set narrowband_ok, add the measured spans to AdapterCaps, document the walls (which widths, which bands) in docs/narrowband.md alongside the other generations.
• Partially qualified (e.g. 10 MHz on 2.4 GHz only) → advertise exactly that and no more.
• Not qualified → remove the narrowband path from src/rtl8733b/ rather than leaving dormant unreachable code. Per project policy, no dead code ships; if it cannot be qualified it should not sit in the tree implying a future.

Acceptance criteria

• docs/rtl8733b.md "Narrowband status" replaced by a measured result — width × band matrix with OBW numbers and the peer-decode evidence — or by a removal note.
• If shipped: AdapterCaps narrowband spans reflect only what was measured, and docs/narrowband.md gains an RTL8733B section with its walls stated as plainly as the 8822B RF re-latch edge and the 5 MHz/5 GHz CFO limit are.

Follow-up to #388. Depends on #390.