[BUG] Bluetooth: MT7922 active LE scan misses ADV_SCAN_IND seen during passive scan

Hello,
I am seeing a repeatable difference between active LE discovery and passive
Advertisement Monitor scanning on a MediaTek MT7922 controller. A changing
Apple manufacturer advertisement is absent from raw HCI reports during active
scan, but appears immediately when the same controller returns to passive
monitoring.

Hardware and software
---------------------

- Bluetooth adapter: MediaTek MT7922 in a Mercusys MA80XE V2
- USB ID: 13d3:3625, bcdDevice 0100
- USB product: MediaTek Inc. Wireless_Device
- Driver: btusb 0.8 / btmtk 0.1
- Controller firmware log:
  `HW/SW Version: 0x008a008a, Build Time: 20260724143815`
- Kernel: 7.1.8-1-cachyos x86_64
- BlueZ: 5.87
- linux-firmware: 20260810
- Remote device: Apple AirPods Pro
- Controller Advertisement Monitor support:
  `controller-patterns`, monitor type `or_patterns`

The relevant legacy scannable advertisement is an ADV_SCAN_IND whose
manufacturer data begins with:

    ff 4c 00 07 19 01

`4c 00` is the Apple company ID and `07 19 01` identifies the status payload
used in this reproducer. The raw btmon entry identifies it as follows:

    Event type: 0x0012
      Props: 0x0012
        Scannable
        Use legacy advertising PDUs
    Legacy PDU Type: ADV_SCAN_IND (0x0012)

Results
-------

All counts below are from raw `> HCI Event: LE Meta Event` advertising reports,
not duplicated MGMT/control renderings. These were separate captures with
different durations and ambient traffic, so the total Apple counts are sanity
checks rather than rates to compare across captures.

1. Clean BlueZ LE-only discovery, no Advertisement Monitor:

   - Extended active scan
   - LE 1M: interval/window 11.25/11.25 ms
   - LE Coded: interval/window 33.75/33.75 ms
   - Filter policy: accept all advertisements
   - Controller duplicate filtering: enabled
   - BR/EDR Inquiry: none
   - Apple advertisements: 64
   - Target `4c 00 07 19 01` advertisements: 0

2. Same normal active discovery with
   `HCI_QUIRK_STRICT_DUPLICATE_FILTER` temporarily enabled through debugfs:

   - The debugfs attribute was present at
     `/sys/kernel/debug/bluetooth/hci1/quirk_strict_duplicate_filter` and
     initially read `N`.
   - The controller was powered down, `Y` was written to that exact attribute,
     the `Y` readback was verified, and the controller was powered up afterward.
   - No Advertisement Monitor was registered; btmon contained zero monitor
     add/program commands.
   - Scan parameters were the same as above.
   - HCI confirmed `Filter duplicates: Disabled (0x00)`.
   - BR/EDR Inquiry: none
   - Apple advertisements: 46
   - Target `4c 00 07 19 01` advertisements: 0

   The controller was powered down again, the attribute was restored to `N`,
   the controller was powered up, and both final states were verified. This
   shows that disabling controller duplicate filtering is not sufficient to
   make this target advertisement appear during active scanning on this setup.

3. Controlled active-to-passive transition during one case-open event:

   - A controller-offloaded Advertisement Monitor pattern for
     `ff:0:4c00071901` was registered.
   - Normal BlueZ LE discovery then ran in active mode for approximately 15
     seconds, with duplicate filtering disabled because monitoring was present.
   - During the active phase: 0 target advertisements.
   - Discovery was stopped, so the existing Advertisement Monitor resumed its
     passive scan.
   - Target ADV_SCAN_IND reports then appeared in the raw HCI stream.
   - During that passive phase: 52 target advertisements.

4. Separate passive Advertisement Monitor capture:

   - HCI confirmed extended passive scan and duplicate filtering disabled.
   - Raw HCI Apple advertisements: 301
   - Raw HCI target advertisements: 206

In that capture the case remained open and untouched across the active-to-
passive transition. No target report appeared in the active portion, while 52
appeared after passive monitoring resumed. Other Apple advertisements continued
to be reported during active scan.

Expected behavior
-----------------

Because passive scanning reports the complete ADV_SCAN_IND in the raw HCI
stream, while repeated active captures report other Apple advertisements but
none matching this target, I expected this PDU to reach the host during active
scanning as well. If this difference is intentional, clarification would be
appreciated.

Questions
---------

- Could the difference originate in the MT7922 active scanning path, for
  example in controller/firmware SCAN_REQ handling for this ADV_SCAN_IND?
- Is there an existing btmtk/controller quirk suitable for forcing passive LE
  discovery on affected hardware, or should this be handled in firmware?
- Would maintainers prefer the complete btmon captures or a smaller btsnoop
  reproducer with device addresses redacted?

As an application-level workaround, registering a BlueZ
AdvertisementMonitor1 pattern and using its passive controller-offloaded scan
reliably receives the packets. The report is about the underlying active-scan
discrepancy rather than that workaround.

Thanks.