BLE-direct MX Master 3 + MX Keys: 'Failed to open device' persists after granting Input Monitoring to all 3 identities + agent restart

## Summary

Following the workaround from #336 (grant Input Monitoring to `OpenLogiAgent`, not just the GUI `OpenLogi`) does **not** resolve `"Failed to open device"` for BLE-direct MX Master 3 + MX Keys, even after granting Input Monitoring to all three related identities and fully restarting the agent process multiple ways.

## Environment

- macOS 26.5.2 (build 25F84), arm64
- OpenLogi 0.7.1 via Homebrew cask
- Devices: **MX Master 3** (pid `b023`) + **MX Keys** (pid `b35b`), both paired **Bluetooth-direct (BLE)** — no Bolt/Unifying receiver
- Logitech StreamCam also connected via USB (works fine, unrelated)

## What was granted (System Settings → Privacy & Security → Input Monitoring)

All three showed up as separate entries and were toggled on:
- `openlogi` (the raw CLI binary at `/Applications/OpenLogi.app/Contents/MacOS/openlogi`)
- `OpenLogi` (the main app bundle, `org.openlogi.openlogi`)
- `OpenLogiAgent` (added manually via Finder "Go to Folder" to `/Applications/OpenLogi.app/Contents/Library/LoginItems/`, since the `+` picker won't browse into the bundle directly — same friction noted in #336)

After each grant, the agent was fully restarted (`launchctl bootout` + `bootstrap` on `org.openlogi.agent`, and separately confirmed by killing all `openlogi-agent` processes and letting launchd respawn). `openlogi list` still reported:

```
WARN openlogi_hid::inventory: failed to open HID++ channel — retrying next tick error=Message("Failed to open device")
```
(x2, once per device, every tick)

## Debug log (OPENLOGI_LOG=debug, agent run manually in foreground after full permission grant + restart)

Enumeration and matching succeed for both devices — this is not a "device unsupported" case, it reaches the same `matched=true` point as the working example in #336:

```
DEBUG openlogi_agent_core::watchers::accessibility: accessibility trust changed granted=false
DEBUG openlogi_hid::transport: logitech HID node name=MX Master 3 pid=b023 usage_page=0xff43 usage_id=0x0202 matched=true
DEBUG openlogi_hid::transport: logitech HID node name=MX Keys pid=b35b usage_page=0xff43 usage_id=0x0202 matched=true
DEBUG openlogi_hid::inventory: HID++ candidate interfaces count=2
WARN openlogi_hid::inventory: failed to open HID++ channel — retrying next tick error=Message("Failed to open device")
WARN openlogi_hid::inventory: failed to open HID++ channel — retrying next tick error=Message("Failed to open device")
```

Note the `accessibility trust changed granted=false` line logged right at agent startup — even though OpenLogi's own in-app Permissions panel showed Accessibility as "Granted" (which per #606 is known to check the GUI's own TCC grant, not the agent's).

## Question / suspected cause

Two candidates, either of which would be useful to confirm or rule out upstream:

1. **TCC daemon caching**: the code signature at `OpenLogiAgent.app` may have been recorded as "denied" by `tccd` on an earlier access attempt (before Input Monitoring was granted), and manually toggling the checkbox afterward doesn't invalidate that cached decision without a full logout/login or reboot — only a process restart, which was tried here and didn't help. If this is the cause, it'd be worth documenting "log out, not just quit-and-reopen" as the real fix, since #336's workaround as written implies a process restart is sufficient.
2. **Accessibility, not just Input Monitoring, may also gate the HID++ open path** for the agent specifically (separate from the GUI's grant) — the debug log shows `accessibility trust changed granted=false` for the agent process even after the GUI shows Accessibility as granted. #674's title ("Removing OpenLogiAgent.app from Privacy → Accessibility permissions breaks macOS input system") suggests Accessibility is load-bearing for the agent in some way beyond event-tap remapping.

Happy to test a build with extra tracing around the `IOHIDDeviceOpen` failure path, or try a full logout if that's a plausible next diagnostic step — wanted to file this since it's a data point where the documented #336 workaround did not fully resolve the issue, unlike the reports in that thread.

Start with the openlogi_hid::transport and openlogi_hid::inventory paths shown in the debug log, then inspect the agent's accessibility trust check. Reproduce the BLE-direct failure with debug logging and trace the IOHIDDeviceOpen failure path. Done means confirming whether TCC caching, agent-specific Accessibility, or another cause explains the failure and documenting the verified workaround.

Written by the indexing model from the issue text.