Add RTL8811AU support via RF_TYPE_ID autodetect

[josephnef]

Summary

• Root cause: EepromManager::read_chip_version_8812a hardcoded RFType = RF_TYPE_2T2R, so the existing 1T1R code paths (PHY_BB8812_Config_1T, the numTotalRfPath loops in PHY_RF6052_Config_8812 / TX power, per-BW L1pkVal branches, 2.4 GHz eLNA threshold) were unreachable on RTL8811AU dongles even though the driver could otherwise drive the chip.
• Fix: derive RFType from REG_SYS_CFG bit 27 (RF_TYPE_ID) the same way Realtek's upstream rtl8812au driver does — set → 1T1R (RTL8811AU), clear → 2T2R (RTL8812AU). Same firmware, same power sequence, same EFUSE layout; only the chain count and a handful of BB constants differ, all of which are already conditionalised.
• Manual override preserved: registry_priv::special_rf_path == 1 still forces 1T1R after autodetect, in case a board's EFUSE/strap is mis-burnt.
• Demo PID widening: demo/main.cpp now tries 0x8812 → 0x0811 → 0xa811 → 0xb811 before giving up. 0xc811 is intentionally excluded — it is shared with the unrelated RTL8811CU chipset, which uses a different driver family entirely and is not supported by this code.

Test plan

Need hardware verification before merge:

• 8812AU regression: plug a known RTL8812AU dongle, run WiFiDriverDemo, confirm log shows RF_Type is 2 TotalTxPath is 2 and beacon RX still works on ch36/20 MHz.
• 8811AU positive: plug a known RTL8811AU dongle (verified via lsusb — VID 0bda, PID one of 0811/a811/b811/8812, not c811), run WiFiDriverDemo, confirm log shows RF_Type is 0 TotalTxPath is 1 and beacons are received.
• TX smoke test: WiFiDriverTxDemo on the 8811AU and confirm the hardcoded beacon is seen by a separate sniffer.
• macOS / Android builds: verify the demo's kRealtekProductIds table still links under _MSC_VER, __ANDROID__, __APPLE__ paths (compile-tested on macOS; the table is static constexpr, no platform-specific behaviour).

Open questions for the reporter (#20)

1. What does lsusb show for your dongle? We need the exact VID:PID to confirm it's an AU and not a CU (which we can't support — separate silicon, separate driver).
2. Does the dongle associate / scan on 5 GHz under aircrack-ng's rtl8812au today? Several upstream issues (e.g. No association when using 5GHz Wi-Fi network (RTL8811AU) aircrack-ng/rtl8812au#793) point to RFE-Type / antenna-byte EFUSE mis-reads on 1T1R variants; if you're affected, the registry_priv::RFE_Type = 64 and AmplifierType_* defaults may need adjusting based on what Hal_ReadRFEType_8812A reports from your EFUSE.
3. Any TX power / link-budget anomalies vs. a 2T2R dongle on the same channel? TxBBSwing_* defaults are EFUSE-driven; calibration on 1T1R SKUs may surface tuning needs.

Refs #20

🤖 Generated with Claude Code