[Bug]: BLE HID++ devices discovered in CLI but fail to surface in GUI + Add Device modal confusion on macOS

### Pre-flight checklist

- [x] I searched [existing issues](https://github.com/AprilNEA/OpenLogi/issues?q=is%3Aissue) and this is not a duplicate.
- [x] I am on the [latest release](https://github.com/AprilNEA/OpenLogi/releases/latest) or a recent `master` build.
- [x] I quit **Logi Options+** before running OpenLogi (the two apps fight over HID++ access and only one can own a receiver at a time).

### Which part of OpenLogi?

GUI (desktop app)

### OpenLogi version

0.7.1

### Operating system

macOS

### OS version & architecture

macOS Tahoe 26.6.2

### Device model

Logitech Lift Vertical Ergonomic Mouse & Logitech MX Keys Mini for Mac

### How is the device connected?

Bluetooth (direct, no receiver)

### Affected area(s)

- [x] Device discovery / detection
- [ ] Button remapping
- [ ] DPI control
- [ ] SmartShift
- [ ] Per-application profiles
- [ ] Battery status
- [ ] Settings / configuration (TOML)
- [ ] Auto-update
- [ ] Menu bar / tray
- [ ] Other

### What happened?

- On initial launch, `openlogi list` returned repeated warnings:
`WARN openlogi_hid::inventory: failed to open HID++ channel — retrying next tick error=Message("Failed to open device")`
- After a clean re-pairing and permission refresh, the CLI successfully discovered both devices and read dynamic telemetry:
```text
LIFT (—, vid=046d pid=b031)
└─ slot 255 ● LIFT VERTICAL ERGONOMIC MOUSE (battery=85%, transports=btle)
MX Keys M Mac (—, vid=046d pid=b36a)
└─ slot 255 ● MX Keys Mini for Mac (battery=90%, transports=btle)
```
GUI Desync / "No devices connected" State:**
- Despite `openlogi list` reporting healthy BLE connections, the GPUI dashboard persistently displayed "No devices connected".
- The status bar indicated `● Accessibility granted`, but did not prompt or indicate missing `Input Monitoring` or Bluetooth TCC permissions required for the GUI client to ingest the agent's pipe.

UX Confusion with "+ Add Device" Modal:**
- Clicking `+ Add Device` triggered a pairing sequence that resulted in:
`Pairing failed: HID transport error: Failed to open device`
- For users connecting via native macOS Bluetooth rather than a Bolt/Unifying receiver, this button creates friction because BLE pairing is handled by macOS settings, not this modal.

### Steps to reproduce

1. Pair a Logitech BLE device (e.g., Lift Vertical Mouse or MX Keys Mini) directly via macOS **System Settings > Bluetooth** without using a Logi Bolt or Unifying receiver.
2. Grant `Accessibility` permissions to OpenLogi when prompted.
3. Verify device detection via CLI:
- Run `openlogi list` in the terminal.
- Confirm that the devices, battery levels, and `transports=btle` slots are properly recognized.
4. Launch `OpenLogi.app` (GUI).
5. Observe that the main window remains stuck on **"No devices connected"** despite the CLI recognizing both active BLE connections.
6. Click the **`+ Add Device`** button in the GUI to attempt manual detection.
7. Observe the resulting error: `Pairing failed: HID transport error: Failed to open device`.

### Diagnostics report

```markdown

```

### `openlogi list` output

```text

```

### Logs

```shell

```

### macOS permissions (if applicable)

- [x] OpenLogi has **Accessibility** permission (needed to remap buttons via the event tap).
- [x] OpenLogi has **Input Monitoring** permission (needed for Bluetooth-direct devices and capture).

Start by comparing the `openlogi list` CLI entry point with the GUI dashboard's device state and the `+ Add Device` pairing flow. Reproduce with a directly paired BLE device on macOS and inspect how permissions and the agent pipe are handled. Done means the GUI surfaces devices the CLI recognizes and the modal gives an appropriate result for native Bluetooth devices.

Written by the indexing model from the issue text.