[Bug]: Changing F-key behavior affects non-logi keyboard too

### 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?

Not sure

### OpenLogi version

0.8.0

### Operating system

Windows

### OS version & architecture

Windows 11 25H2

### Device model

K380

### How is the device connected?

Bluetooth (direct, no receiver)

### Affected area(s)

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

### What happened?

After changing F-key behaviour to any action - any other connected keyboard also affected

### Steps to reproduce

1. Connect Logi keyboard + any other USB keyboard
2. Setup Logi keyboard - Keys - remap F-key to any action
3. Press F-key on non-Logi keyboard - overriden action invoked

### Diagnostics report

```markdown

```

### `openlogi list` output

```text

```

### Logs

```shell

```

### macOS permissions (if applicable)

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

Reproduce the reported button-remapping behavior on Windows with a Logitech K380 connected over Bluetooth and a second USB keyboard, following the listed steps. Trace the remapping input path and verify that changing an F-key action on the Logitech device no longer invokes that action when the same key is pressed on the other keyboard.

Written by the indexing model from the issue text.