Bluetooth: SCO packet for unknown connection handle on repeated HFP voice joins (Realtek 8761BU, mSBC eSCO)

Hello,

Reporting an SCO connection-lifetime race on repeated hands-free voice
sessions. First voice join after a clean state works; every subsequent
join fails the same way, which matches the pattern of a pending SCO
object being deleted before the controller completes setup.

Hardware/software (all verified, stock, no local kernel mods):
- OS: CachyOS Linux, kernel 7.2.4-3-cachyos (SMP PREEMPT_DYNAMIC)
- bluez 5.87, pipewire 1.6.8, wireplumber 0.5.17
- Adapter: Realtek 0bda:8771 USB (btusb/btrtl)
- Headset: soundcore Space One (A3035), fw 06.94, single connection
  (no multipoint), HFP codec mSBC
- bluetooth kernel module stock (on-disk srcversion == running),
  disable_esco=N
- USB autosuspend disabled (verified) — issue persists without it

Pattern:
- 1st join: single teardown burst in logs, then silence + working
  two-way audio.
- 2nd+ joins: transport Acquire/Start failures in a loop every
  ~5-20s, mic present but silent, card profile ends at "off",
  then auto-reverts to A2DP.
- Manually pre-setting the headset profile before joining works 100%
  (no mid-join switch → no race). Full BT reconnect also restores
  normal behavior temporarily.

Kernel log (journalctl -k):
  Bluetooth: hci0: SCO packet for unknown connection handle 2 (x2)
  Bluetooth: hci0: SCO packet for unknown connection handle 3
  Bluetooth: hci0: SCO packet for unknown connection handle 6
  Bluetooth: hci0: SCO packet for unknown connection handle 9
  Bluetooth: hci0: SCO packet for unknown connection handle 10

PipeWire loop during a failed join:
  spa.bluez5: Failure in Bluetooth audio transport .../sep3/fd0
  spa.bluez5: Failure in Bluetooth audio transport .../fd51
  pw.node: (bluez_input....) suspended -> error (Start error: I/O)
  (node incarnations climb continuously)

HCI capture (btmon, 35s window of one failed join):
- +CIEV: 2,1 → Setup Synchronous Connection → Command Status:
  Success → Synchronous Connect Complete — eSCO comes up cleanly
- ~3300 bidirectional eSCO packets flow, application hears silence
- at ~26.9s the host tears it down (HCI Disconnect, Complete:
  Terminated By Local Host) and A2DP bulk traffic resumes

Full diagnose.sh output (redacted):
https://gist.github.com/ShredRum/f59bdd2296c44916930967e0e4633e0f
Full 2 MB .snoop available on request (too large for the list).

This was also documented with full timelines at:
https://github.com/Mr-V1be/linux-bluetooth-headset-mic-fix/issues/2

Two questions:
1. Are abd93c85c866 ("give the socket its own sco_conn reference")
   and 8a5b0135d4a5 ("fix races in sco_sock_connect()") expected to
   cover this path in 7.2.x? The race reproduces on 7.2.4.
2. Is there anything specific (btmon filters, debug flags, test
   patches) you would like captured next? Happy to test.

Thanks,
Aleksey