Follow-ups left open by the Kestrel 80 MHz review (#494) #495

Two items left open by the review of #494 (merged as 357f045). Neither was blocking; both were verified against the vendor source during review, not measured on hardware.

1. mac_set_bw_txsc logs at info on every same-block hop

HalKestrel::mac_set_bw_txsc emits Kestrel set_channel: pri .. center .. rfmod .. txsc .. at info whenever the width is wide, and fast_set_primary_80 calls it on every hop (the review's hop cell wrote one line per hop). The ~3 ms same-block hop exists for slot-cadence hopping (DEVOURER_HOP_SLOT_MS, 10 ms slots), where that is ~100 flushed stderr lines/s at the demos' default log level. The existing fast_retune logs its per-hop line at debug.

Fix: debug level, or log only from the set_channel call site.

2. The vendor pairs RFMOD + TXSC with R_AX_TXRATE_CHK; devourer never writes it

Vendor mac_set_bw (reference/rtl8852cu/phl/hal_g6/mac/mac_ax/hw.c) writes R_AX_TXRATE_CHK (0xC628, mask 0x13) in the same step as R_AX_WMAC_RFMOD and R_AX_TX_SUB_CARRIER_VALUE: B_AX_BAND_MODE on 2.4 GHz, B_AX_CHECK_CCK_EN | B_AX_RTS_LIMIT_IN_OFDM6 on 5/6 GHz. Nothing under src/kestrel/ touches that register, on either die. Pre-existing before #494, which ported the other two writes "as rtw89 rtw8852c_set_channel_mac".

No measured failure. The plausible consumer is the MAC-chosen rate of hardware-generated responses (the ACK responder from #489 on 5 GHz, RTS/protection), which is what this register gates. Either port it alongside mac_set_bw_txsc and measure the responder's response rate before/after on 5 GHz, or record in src/kestrel/CLAUDE.md that it is deliberately left at the CMAC-init default and why.