T1: port StopTxBeacon — clears MAC 0x420[22] in monitor mode init

[josephnef]

Summary

Closes one more T1 canary-diff line. Pre-fix at any channel:

MAC 0x420 byte 2: kernel = 0x31, devourer = 0x71

Bit 22 (= BIT6 of byte 2 = "HW treats packet as real beacon" enable) was at the chip's reset-state 1 on devourer; kernel had it cleared by StopTxBeacon.

Root cause

Upstream's rtw_hal_set_hwreg(HW_VAR_NET_TYPE, ...) path (hal_com.c:14283) calls StopTxBeacon(Adapter) whenever the MSR transitions to _HW_STATE_NOLINK_ or _HW_STATE_STATION_ and no AP/mesh port is up. StopTxBeacon body (hal_com.c:14158):

rtw_write8(REG_FWHW_TXQ_CTRL + 2,
           rtw_read8(REG_FWHW_TXQ_CTRL + 2) & ~BIT6);
rtw_write8(REG_TBTT_PROHIBIT + 1, TBTT_HOLD_STOP_BCN & 0xff);
rtw_write8(REG_TBTT_PROHIBIT + 2,
           (rtw_read8(REG_TBTT_PROHIBIT + 2) & 0xf0) |
           (TBTT_HOLD_STOP_BCN >> 8));

devourer's _InitNetworkType_8812A set MSR to NT_NO_LINK (PR #64) but didn't call StopTxBeacon afterwards. Port the body inline so monitor-mode init matches the kernel's MSR-transition handler.

Test plan

• Build clean.
• DEVOURER_DUMP_CANARY=1 at ch6 confirms MAC 0x420 now matches kernel 0xFF311F00 (was 0xFF711F00). Verification pending: 8812 dongle dropped off USB during this PR's prep — re-plug + re-capture once the rig stabilises.
• No regression on the matrix at ch6/ch36/ch100 — the fix is cosmetic to live operation (monitor mode doesn't use HW beacon TX), so no behavioural change expected.

🤖 Generated with Claude Code