[Bug]: BLE-direct devices are probed sequentially (~10-15s each) on macOS; GUI shows partial inventory and bindings apply late after login

### Pre-flight checklist

- [x] I searched existing issues (related: #707, but that one is about a permission failure; this is a timing/partial-inventory problem with permissions already granted)
- [x] I am on the latest release (v0.7.10)
- [x] This is not a device support request

### Which part of OpenLogi?

Agent + Desktop GUI

### OpenLogi version

0.7.10

### Operating system

macOS

### OS version & architecture

macOS 26.5.2, Apple Silicon (arm64)

### Device model

MX Keys Mini (046d:b369, fw RBK73.04_0016) and MX Master 4 (046d:b042, fw RBM27.02_0017)

### How is the device connected?

Bluetooth LE direct (no Bolt receiver), both devices paired via macOS System Settings

### Affected area(s)

- [x] Device discovery / inventory
- [x] Desktop GUI

### What happened?

After the agent starts (login, or `launchctl kickstart -k gui/$UID/org.openlogi.agent`), BLE devices show up in the agent inventory one at a time with a long delay per device, and the GUI redraws a partial device list in the meantime.

Measured with `openlogi list` polling right after an agent restart:

- t+6s: only MX Master 4 listed
- t+20s: both MX Master 4 and MX Keys Mini listed

A second restart gave the reverse order (keyboard first, then mouse ~15s later). The GUI mirrors this: it shows one device, then the other appears while the first one briefly disappears, then both settle. Button/key bindings for a device are not applied until that device finishes probing, so for the first 20-30s after login remaps do not work.

macOS itself sees both devices immediately (`ioreg -c IOHIDDevice` lists both with Transport = "Bluetooth Low Energy" the whole time), so this is not a Bluetooth reconnect delay. It looks like BLE HID++ probing is sequential and each device takes roughly 10-15s to enumerate.

Environment notes:

- Input Monitoring is granted to OpenLogi Agent (no "Failed to open device" errors; this is not the failure in #707 / #891)
- Logi Options+ and all Logitech launch agents/daemons were fully removed before measuring; no other HID++ client is running
- Once both devices have appeared they stay stable until the next agent restart or sleep/wake

### Expected behavior

Both BLE devices should appear within a few seconds of the agent starting, ideally probed in parallel, and the GUI should not drop an already-discovered device from the list while another one is still being probed.

### Steps to reproduce

1. Pair two Logitech BLE devices (keyboard + mouse) directly in macOS Bluetooth settings, no Bolt receiver
2. Grant Input Monitoring to OpenLogi Agent
3. Run `launchctl kickstart -k gui/$UID/org.openlogi.agent`
4. Run `/Applications/OpenLogi.app/Contents/MacOS/openlogi list` every few seconds and watch the GUI device list

Reproduce with two paired BLE devices by running the launchctl kickstart command, polling openlogi list, and comparing with ioreg -c IOHIDDevice. Then trace agent discovery and the Desktop GUI inventory updates. Done means both devices appear promptly after restart, the list remains stable during probing, and bindings apply without waiting 20–30 seconds.

Written by the indexing model from the issue text.