[Bug]: macOS — granting Input Monitoring has no effect until the agent's launchd job is restarted, so "Try again" can never succeed

### Pre-flight checklist

- [x] I searched [existing issues](https://github.com/AprilNEA/OpenLogi/issues?q=is%3Aissue) and this is not a duplicate. *(This may well be the root cause behind #1261 and #1135 — both describe "permission is granted but OpenLogi says it isn't". Filing separately because I have the exact mechanism and a one-command fix; happy to have it merged into #1261.)*
- [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 (never installed on this machine).

### Which part of OpenLogi?

GUI (desktop app)

### OpenLogi version

0.8.3 (build `20260830.162827`), signed DMG install in `/Applications`

### Operating system

macOS

### OS version & architecture

macOS 26.5.2 (25F84), arm64 (Apple Silicon)

### Device model

MX Mechanical Mini (keyboard) + MX Vertical (mouse)

### 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
- [x] Other

### What happened?

**Summary: once `openlogi-agent` has been denied Input Monitoring, granting the permission has no effect until the launchd job is restarted — and nothing in OpenLogi ever restarts it. "Try again" retries inside the same process, so it can never succeed.**

Add Device failed with:

> HID transport error: Failed to open device: Input Monitoring is NOT granted to this process; grant it to OpenLogi Agent under System Settings → Privacy & Security → Input Monitoring

The permission *was* already granted. `~/.local/state/openlogi/agent..log` shows the same error repeating every ~2 s for ~18 minutes while the toggle was on. Then, with **zero** changes to any permission:

```
launchctl kickstart -k gui/$(id -u)/org.openlogi.agent.service
```

and the agent opened the HID++ channel on the first attempt. Both devices appeared immediately, with battery levels.

**Why this happens:** on macOS the Input Monitoring (`kTCCServiceListenEvent`) decision is resolved for a process when it starts, and a running process does not pick up a grant made afterwards — the same reason System Settings tells apps to quit and reopen. `openlogi-agent` is a `KeepAlive` launchd job registered through `SMAppService` (`parent bundle identifier = org.openlogi.openlogi`), so:

- toggling the switch in System Settings does not restart it;
- quitting and reopening **OpenLogi.app** does not restart it either — launchd keeps the agent alive across GUI restarts;
- so the only exit from the bad state is a `launchctl kickstart`, a logout, or a reboot — none of which the app suggests.

Anyone who installs OpenLogi, hits the permission error, grants the permission, and clicks **Try again** is stuck in a loop that looks like the permission itself is broken.

**Secondary problem — the error text sends users to a row that doesn't exist.** It says to grant it *to OpenLogi Agent*, but on my machine Input Monitoring only ever lists a single row, **OpenLogi** (the parent bundle), and after the agent restart that single grant was enough to cover the helper. There is no separate "OpenLogi Agent" row to enable. That is exactly the dead end reported in #1261 ("I have even added OpenLogi agent to no success").

### Steps to reproduce

1. Install 0.8.3 (signed DMG) on macOS 26, launch it, let the login-item agent start. Do **not** grant Input Monitoring yet.
2. Open **Add Device** → "Pairing failed", with the Input Monitoring message. The agent log starts repeating the error every ~2 s.
3. Go to System Settings → Privacy & Security → Input Monitoring and enable **OpenLogi**. Leave the app and the agent running (this is what a user naturally does — the toggle is presented as the fix).
4. Click **Try again** → same failure. Quitting and reopening OpenLogi.app also does not help, because the agent is a separate launchd job that survives.
5. Run `launchctl kickstart -k gui/$(id -u)/org.openlogi.agent.service` → devices are detected instantly, no permission changes needed.

### Suggested fix

- When a HID open fails with a TCC denial, have the GUI (or the agent itself) **restart the launchd job** rather than retrying in-process — e.g. wire **Try again** and the Permissions pane's Input Monitoring row to a kickstart / `SMAppService` re-register, or have the agent re-exec itself once it observes `IOHIDCheckAccess` flip to granted.
- At minimum, change the copy to say the agent must be restarted after granting, and name the row users will actually see (**OpenLogi**, not "OpenLogi Agent"). The GUI already has a "Relaunch OpenLogi" affordance for updates; a "Restart agent" button here would remove the dead end entirely.

### Diagnostics report

```markdown
- OpenLogi (GUI): v0.8.3 (release, signed DMG)
- Agent: v0.8.3, launchd job org.openlogi.agent.service (SMAppService, KeepAlive, parent bundle org.openlogi.openlogi)
- OS: macOS 26.5.2 (25F84), arm64
- Accessibility: granted (agent logs "accessibility granted — installing OS mouse hook" on every start)
- Input Monitoring: granted — one row, "OpenLogi"; no "OpenLogi Agent" row is ever offered
- Code signature: Developer ID Application: AprilNEA LLC (8U3ZJ258K9), all three bundles
- Devices: MX Mechanical Mini + MX Vertical, both BLE-direct
```

### `openlogi list` output

```text
(inventory read from the running agent)
MX MCHNCL M (—, vid=046d pid=b367)
└─ slot 255 ● MX Mechanical Mini (keyboard, wpid=?, battery=100% full (discharging))
model_ids=[b367,0000,0000] ext=00 serial= unit_id=341c5c6d transports=btle

MX Vertical (—, vid=046d pid=b020)
└─ slot 255 ● MX Vertical Advanced Ergonomic Mouse (mouse, wpid=?, battery=90% full (discharging))
model_ids=[b020,407b,c08a] ext=00 serial=— unit_id=417ddba9 transports=usb+equad+btle
```

(This is the state *after* the agent restart — before it, the inventory was empty.)

### Logs

Agent process had been running since 23:57:54; the Input Monitoring toggle was switched on while it ran. `~/.local/state/openlogi/agent..log`:

```shell
# ~18 minutes of this, every ~2 s, with the permission already granted:
00:02:44 WARN openlogi_device::inventory: failed to open HID++ channel — requesting repair error=Backend("Failed to open device: Input Monitoring is NOT granted to this process; grant it to OpenLogi Agent under System Settings → Privacy & Security → Input Monitoring")
...
00:15:55 WARN openlogi_device::inventory: failed to open HID++ channel — requesting repair error=Backend("Failed to open device: Input Monitoring is NOT granted to this process; ...")

# launchctl kickstart -k gui/501/org.openlogi.agent.service — no permission was changed:
00:15:50 INFO openlogi_agent::shutdown: releasing the input hook and exiting reason="shutdown signal"
00:15:50 INFO openlogi_agent::server: IPC server listening
00:15:50 INFO openlogi_agent::lifecycle: openlogi-agent started
00:15:50 INFO openlogi_agent::lifecycle: accessibility granted — installing OS mouse hook
00:15:51 INFO openlogi_agent_core::watchers::inventory: system resume — replaying settings on a settled inventory
00:15:55 INFO openlogi_device::session::gesture: control capture active index=255 ... dpi_buttons=1 ...

# zero occurrences of "Input Monitoring is NOT granted" after the restart
```

### macOS permissions (if applicable)

Accessibility: granted. Input Monitoring: granted to **OpenLogi** (single row, parent bundle — it does cover the agent, but only from the agent's next launch onward).

Start at the GUI's Add Device "Try again" flow and the agent's HID-open/TCC-denial handling, then trace how the launchd job is registered through SMAppService. Verify the fix by granting Input Monitoring and using "Try again" without a manual restart, confirming that devices appear and the message names the OpenLogi row users actually see.

Written by the indexing model from the issue text.