[Bug]: Does not remap F17/Screen capture on MX Keys S

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

Windows

### OS version & architecture

Windows 11 x86_64

### Device model

MX Keys S

### How is the device connected?

Logi Bolt 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?

Run from zip, since MSI installer currently fails in the middle as described in #666

Running the GUI, the keyboard is presented correctly, the Bolt receiver is identified, the battery state is presented as expected (charging at the moment)

- when remapping F17 key to screen capture, Paste, or anything else - none of those things happens
- when remapping F11 key to screen capture, paste, etc - those actions do happen.

The F17 I expect is impacted by something already mentioned here: #431

It also appears that Screen Capture/Region Capture action actually still triggers that pesky windows capture utility... so can a [Print Scr] mapping be added so that apps expecting this key (not available on MX Keys S at all!) could function as expected? Original Logi Options+ was able to do that.

### Steps to reproduce

mentioned above

### Diagnostics report

```markdown
### OpenLogi Diagnostics

**App**
- OpenLogi (GUI): v0.7.1 (release)
- Agent: v0.7.1 (connected)
- IPC protocol: GUI 17 / agent 17
- Inventory: ready
- OS: Windows (x86_64)
- Locale: pl-PL (UI: follow system)
- Accessibility: granted · Input hook: installed
- Launch at login: yes · Menu bar: yes · Update check: off
- Running from: source build (dev)
- Config: schema 4 · 1 configured device(s) · thumbwheel 14

**Assets**
- Source: user cache · Index: loaded (210 models) · User cache: present
- Cache path: %user_profile%\.local\share\openlogi\assets · Bundle assets: absent

**Devices (1)**
- MX Keys S — keyboard (codename: MX KEYS S)
- Connection: Logi Bolt receiver · Online: yes · Battery: 45% (charging, good)
- Capabilities: buttons=yes, pointer=no, lighting=no
- Model: 0b378 (model-ids: b378/0000/0000, ext-model: 00)
- Transports: BTLE
- Render: mx_keys_s · Slot 1

**Receivers (1)**
- Logi Bolt Receiver (VID 046d / PID c548)
```

### `openlogi list` output

```text
nothing, just opens the GUI
```

### Logs

```shell
nothing
```

### 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 issue in the GUI with an MX Keys S connected through a Logi Bolt receiver, assigning F17 and F11 to the same actions. Compare the observed remapping behavior and verify that F17 triggers the selected action, while checking the related behavior described in #431; completion should also clarify whether Print Screen mapping is in scope.

Written by the indexing model from the issue text.