Crash loop after Bluetooth adapter renumbers (hci0 -> hci1): hardcoded /org/bluez/hci0 path

[sterlizzi]

Summary

On resume from suspend, my Intel Bluetooth controller failed its in-place kernel reprobe and came back as hci1 instead of hci0 (kernel: BT reprobe failed for BDF:0000:00:14.7, followed by a full firmware re-load under the hci1 index). From that point on, magicpodscore 2.0.8 crash-loops on every startup attempt.

Evidence

1. Original crash, mid adapter-power-off event, glibc heap corruption:

[DBus] Bluetooth adapter powered OFF, scanning stopped
INF OnDefaultAdapterChangeEnabled Broadcast was triggered
double free or corruption (!prev)

(SIGABRT, backtrace shows glibc's malloc integrity-check abort path called from inside nested libsystemd sd-event dispatch frames — consistent with corruption in the adapter-changed D-Bus signal callback.)

2. Every restart since then fails immediately during startup with an unhandled exception:

INF Starting initialization...
terminate called after throwing an instance of 'sdbus::Error'
  what():  [org.freedesktop.DBus.Error.UnknownObject] Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

3. Root cause confirmed via strings on the binary: it contains the literal path /org/bluez/hci0. It does not appear to discover the adapter dynamically via BlueZ's org.freedesktop.DBus.ObjectManager.GetManagedObjects (or by watching InterfacesAdded/InterfacesRemoved). Once the kernel/BlueZ assign the controller a different index (hci1 in my case — I verified via busctl tree org.bluez that only /org/bluez/hci1 exists, no hci0), every Properties.Get call against the hardcoded path fails with UnknownObject and the app aborts via an uncaught exception, forever, until reboot.

Environment

• magicpodscore 2.0.8 (latest release), run as a systemd user service
• Arch Linux (Omarchy), Intel AX-series Bluetooth controller, kernel hci_intel/btintel driver
• ~/.config/magicpods/config.toml has no adapter-selection option to work around this

Request

1. Discover the Bluetooth adapter dynamically (via ObjectManager.GetManagedObjects / org.bluez.Adapter1 interface presence, or by watching for adapter add/remove signals) instead of hardcoding /org/bluez/hci0, so the app survives adapter renumbering without requiring a reboot.
2. Wrap the D-Bus Properties.Get calls (and other adapter calls) in the adapter-changed handler with proper exception handling instead of letting sdbus::Error propagate uncaught into std::terminate().

Happy to provide the full coredumpctl info output or a symbolized backtrace if useful.