Please backport two btusb/btrtl commits for RTL8761BU to 7.1.y, 6.18.y, 6.12.y and 6.6.y

Hello,

Could you please pick these two mainline commits into 7.1.y, 6.18.y, 
6.12.y and 6.6.y:

```
bc597f0cc44f ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV”)
5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended 
scan”)
```

Both landed in v7.2-rc1. They went through bluetooth-next, so neither 
carries a Cc: stable and AUTOSEL did not pick them up.

The first commit is a plain device ID addition. The TP-Link UB600 is an 
RTL8761BUV sold under TP-Link's own USB ID 37ad:0600, and without that 
entry btusb never sets BTUSB_REALTEK, so btrtl never uploads 
rtl_bt/rtl8761bu_fw.bin and the chip stays on ROM firmware.
hci0 comes up and reports itself powered and discovering, but it never 
delivers a single LE advertisement and the interrupt URBs die, so dmesg 
fills with

```
Bluetooth: hci0: urb 000000009204cf55 failed to resubmit (2)
```

Hence, the adapter is unusable in that state. The ID is the only thing 
missing, rtl8761bu_fw.bin already ships in linux-firmware, and btrtl 
already seems to handle the 8761BU. I checked that the commit applies to 
7.1.y, 6.18.y, 6.12.y and 6.6.y unchanged.

The second commit matters as soon as the first one works. The 8761B and 
8761BU report HCI 5.1 but do not implement the LE extended scan 
commands, so extended scanning fails with Opcode 0x2042 returning -EBUSY 
whenever a connection is active. Backporting only the device ID would 
leave people with a dongle that enumerates and then logs errors 
continuously.

For context, i’ve Home Assistant OS 18.2 running kernel 6.18.39 as an 
immutable image with no kernel headers and no dkms, so users like me 
cannot patch btusb themselves and have no workaround.

Thanks,
Ștefan Muraru