[BUG] wifi: rtw89: firmware regression on RTL8922AE (0.35.80.3 vs 0.35.42.1)

Hardware: Realtek RTL8922AE (rtw89_8922ae driver)
Also tested on: RTL8922AE-VS (same PCI ID: 10ec:8922)
Systems: Lenovo Yoga 7 14AKP10 (Type 83JR) [laptop, PCIe],
         desktop (RTL8922AE via M.2-to-PCIe adapter, replacing a
         QCNFA765/ath11k card)
Kernels tested: CachyOS default, CachyOS zen, Arch (vanilla),
                mainline LTS — regression reproduces identically
                on all of them, ruling out kernel version as a
                variable.

=== ISSUE 1: Firmware regression, reproduced across two
    linux-firmware releases ===

Known-good firmware:
  Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 1
  Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 3

Known-bad firmware:
  Firmware version 0.35.80.3 (8ef4f0cf), cmd version 1, type 1
  Firmware version 0.35.80.3 (8ef4f0cf), cmd version 1, type 3

Symptoms on the bad firmware (0.35.80.3):
  - Intermittent disconnects on both 5GHz and 6GHz, under load or after 3-5 minutes
    (observed most reliably during sustained transfer / speedtest)
  - Recurring log line preceding drops:
      "rtw89_8922ae 0000:03:00.0: sec cam entry is empty"
  - Followed by reassociation failures:
      "wlan0: deauthenticated from <MAC> while associating
       (Reason: 9=STA_REQ_ASSOC_WITHOUT_AUTH)"
  - Ruled out as the cause before landing on firmware:
      DFS channel-vacate events, router DCS (dynamic channel
      selection), PCIe ASPM L1, GTK/group-rekey interval,
      kernel choice (4 different kernels tested)

Reproduction:
  1. Install current linux-firmware (rtw8922a_fw-4.bin loads,
     version 0.35.80.3)
  2. Sustained transfer / speedtest on 5GHz or 6GHz, wide channel
     (160MHz+) — disconnect + "sec cam entry is empty" +
     reason-9 reassoc failure within minutes
  3. Move/delete the -3.bin and -4.bin firmware files so the
     driver falls back to an earlier bundled version
     (0.35.42.1 (cc364c30) loads) — stable indefinitely under
     the same load/test conditions

This was independently reproduced a second time after a
subsequent linux-firmware update reintroduced the same -3/-4
files — same fix (remove them, fall back to 0.35.42.1) resolved
it identically both times. Confirms this isn't a one-off but a
persistent regression carried across releases.

Happy to test candidate fixes or provide a fuller dmesg/pcap
capture around a live drop if useful — I have the reproduction
steps down to a few minutes reliably.

=== ISSUE 2 (informational, not a bug report): MLO/MLSR real-world
    test data ===

Tested the MLO patchset (MLSR — link-switching) with an AP
broadcasting one SSID across 5GHz and 6GHz simultaneously.
AP-side confirms the client associated on both bands at once.
`iw dev wlan0 station dump` shows only a single active tx/rx
bitrate pair at a time (consistent with MLSR link-switching
rather than MLMR aggregation, as expected given the current
patchset).

Real-world throughput/quality comparison from the same physical
location (one interior wall between client and AP), same
firmware (0.35.42.1):

  5GHz, 240MHz (160+80 non-contiguous), separate SSID:
    RSSI: -34 to -57 dBm
    MCS: steady EHT-MCS 8-11 (2 streams), occasionally EHT-MCS 13
    iperf3 -P4: 728 Mbit/s aggregate, 81 retransmits/30s

  6GHz, 160MHz, separate SSID:
    RSSI: -65 dBm (AP has no AFC — confirmed with vendor, LPI-only,
          23dBm ceiling on 6GHz)
    MCS: oscillating EHT-MCS 5-7 (2 streams)
    iperf3 -P4: 889 Mbit/s aggregate, 800 retransmits/30s
    (~8x more retransmits per Mbit/s than the 5GHz link)

Sharing in case it's useful data for prioritizing MLSR vs. MLMR
work, or for anyone else's testing/comparison — not filing this
half as a bug, more as real-world confirmation that link quality
(not just raw throughput) matters for whichever link MLSR
switching logic favors.

System info:
  $ lspci -nn | grep -i realtek
  07:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8922AE 802.11be PCIe Wireless Network Adapter [10ec:8922] (rev 01)

  $ uname -a
7.1.8-1-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 10 Aug 2026 19:39:40 +0000 x86_64 GNU/Linux
  $ dmesg | grep -i "rtw89.*Firmware version"
  [    7.404909] rtw89_8922ae 0000:07:00.0: Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 1
[    7.404912] rtw89_8922ae 0000:07:00.0: Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 3
[    7.427821] rtw89_8922ae 0000:07:00.0: Firmware version 0.1.0.0 (86ec27bf), cmd version 0, types