RTL8733B: vendor-driver A/B control missing — build the vendor module in a pinned-kernel VM

[josephnef]

Every other generation in this tree has been A/B'd against its vendor kernel driver on the same hardware. The RTL8733B backend merged in #388 has not — the attempt failed at the build step, so no vendor-driver parity result exists for this silicon.

Without that control, any future "the RF is the limit" conclusion on this chip is unsupported: a devourer-only measurement cannot distinguish a driver-side ceiling from a hardware one.

What was attempted and how it failed

libc0607/rtl8733bu-20240806 on Linux 6.14:

1. The Makefile omitted required include paths.
2. After supplying the main include path, compilation stopped on an incompatible MODULE_IMPORT_NS use.
3. A missing platform_ops.h.

No module was ever loaded. Note the tree pinned as reference/rtl8733bu-20230626 (commit 9e5f684, the generator input) was not the one built — it may fare better or worse.

Work items

1. Build the vendor module in the pinned-kernel VM, not on the host. tests/setup_vm.sh provisions exactly this, and it is the established answer for vendor drivers that do not build on bleeding-edge kernels — the RTL8814AU has the same story. MODULE_IMPORT_NS syntax churn and missing headers are kernel-version symptoms; picking the kernel is cheaper than patching the driver.
2. Decide which tree is the control. The 2023 tree is what devourer's firmware, tables and register constants were extracted from, so it is the more faithful control. Build that one first; use 2024 only if 2023 cannot be made to run.
3. Run the matrix. tests/regress.py 2×2 (devourer vs kernel driver, TX and RX) against a second adapter, on 2.4 GHz and 5 GHz — a single-band matrix is not comprehensive.
4. Record the result either way. "The vendor driver does not build / does not run on any kernel we are willing to pin" is a legitimate, documentable outcome. What is not acceptable is the current silent absence.

Traps

• Never rtw88. Its monitor injection does not reliably radiate, so an rtw88-based baseline is the wrong baseline — it would produce a control that is worse than no control. Vendor trees from reference/ only.
• The in-tree Realtek modules auto-probe and firmware-download into every Realtek dongle at each enumeration, and modprobe -r does not survive re-enumeration. Temp-blacklist instead.
• A kernel driver pre-initializing the chip masks the cold-boot path — the same reason the Kestrel work blacklists rtw89 during testing.
• Qualify the receiver before believing any delivery number on either side of the A/B (tests/ground_station_qualify.sh); prefer an external-antenna adapter as the ground station.

Acceptance criteria

• Either a tests/regress.py matrix with vendor-driver cells populated on both bands, or a documented statement in docs/rtl8733b.md of exactly which trees were tried, on which kernel, and where each failed.
• If parity gaps appear, they become their own issues rather than footnotes.

Follow-up to #388. Best run alongside #392 (a second board makes the 2×2 matrix possible without borrowing the only known-good unit).