ASUS USB-BT500 not working properly after first use with Bumble, works again after reset

I'm doing an ordinary outbound RFCOMM connect that begins with an SDP browse to a Bluetooth Classic accessory. After the first run of my program to successful completion, upon the next run, the controller locks up after establishing the bidirectional ACL link. I have noticed that after re-plugging the dongle, it starts working again. For now, my best idea is to just reset the controller inside my program upon startup.

I'm not sure whether it's a firmware issue, or Bumble does something upon termination that leaves the controller in a bad state, or maybe I'm using Bumble in a way that causes this... Since I'm very new to all of this, I'd appreciate any help.

## Steps to reproduce

1. Physically plug in an ASUS USB-BT500 dongle
2. Run a Bumble script that connects to a Classic peer and does an SDP browse → **works**
3. Let the script exit normally; do not unplug anything
4. Run the same script again → **hangs; no L2CAP channel is ever established**
5. `usb.core.find(idVendor=0x0b05, idProduct=0x190e).reset()`, then run again → **works**

## Environment

| | |
|------------------|--------------------------------------------|
| Bumble | 0.0.233 |
| Python | 3.14.4 |
| OS | macOS 15.7.7 (arm64) |
| Transport | `usb:0` |
| Dongle | ASUS USB-BT500, VID `0x0B05` PID `0x190E` |
| Controller | Realtek (manufacturer 93), RTL8761B |
| ROM firmware | HCI v10 rev 11, LMP v10 subver `0x8761` |
| Patched firmware | HCI v10 rev 57286, LMP v10 subver `0xd922` |

## Details

I've looked at the `BUMBLE_SNOOPER` capture and noted the following:

* The peer **is** reachable and does respond — its `Info_Req` arrives normally. So the ACL link is up and bidirectional at least briefly.

* After the host's `Info_Rsp`, **no further inbound ACL data arrives at all** — 1 inbound packet versus 47 in a working run. The host eventually times out and disconnects.

* The controller reports `Number_Of_Completed_Packets count=1` for each ACL packet the host submits, i.e. it claims to have transmitted them. I cannot tell whether the controller stops transmitting or stops delivering received packets upward.

* `HCI_Reset` (which Bumble does issue) does not clear the condition.

Start by running the listed Bumble script twice with the ASUS USB-BT500 on the stated macOS and Python environment, then compare the BUMBLE_SNOOPER captures from the working and hanging runs. Investigate the USB transport and controller lifecycle around normal exit, HCI_Reset, ACL traffic, and the reported completed-packet events. Done means the repeat-run failure is reproduced and its firmware, Bumble shutdown, or usage cause is identified with a corrective change or documented workaround.

Written by the indexing model from the issue text.