[Bug]: MX Master 3 gesture button is never claimed in gesture mode (gesture_sources=1 but gesture_buttons=0); works as a plain action

### Pre-flight checklist

- [x] I searched existing issues. The closest are #1199 and #1262; both differ — see "Not a duplicate of" below.
- [x] I am on the latest release (0.8.3).
- [x] Logi Options+ is not installed on this machine, so there is no HID++ contention.

### Which part of OpenLogi?

Agent

### OpenLogi version

0.8.3 (Arch/AUR `openlogi-bin` v0.8.3-1)

### Operating system

Linux — Omarchy 4.0.3 (Arch), kernel 7.2.4, Hyprland 0.56.2, `XDG_SESSION_TYPE=wayland`

### Device model

MX Master 3 (`046d:b023`), `unit_id=d3de6f91`

### How is the device connected?

Bluetooth-direct (no receiver), `hidraw` bus `0005`, `transports=equad+btle`

## What happened?

With the thumb button configured as a **gesture-direction map**, the agent never claims it and no direction does anything:

```toml
[devices."unit:".bindings.GestureButton]
Click = { CustomShortcut = "Ctrl+Alt+c" }
Up = { CustomShortcut = "Ctrl+Alt+u" }
Down = { CustomShortcut = "Ctrl+Alt+d" }
Left = { CustomShortcut = "Ctrl+Alt+q" }
Right = { CustomShortcut = "Ctrl+Alt+w" }
```

Agent log on every start:

```
INFO openlogi_device::session::gesture: control capture active index=255
gesture_sources=1 gesture_buttons=0 dpi_buttons=1 buttons=0
thumbwheel=false wake_rearm=true
```

Note `gesture_sources=1` — the source **is** discovered — while `gesture_buttons=0`.

Changing nothing else, binding the same physical button as a **plain action** makes it work immediately:

```toml
[devices."unit:".bindings]
GestureButton = { CustomShortcut = "Ctrl+Alt+w" }
```

```
INFO openlogi_device::session::gesture: control capture active index=255
gesture_sources=0 gesture_buttons=0 dpi_buttons=1 buttons=1
...
```

`buttons=1`, and pressing the thumb button fires the shortcut reliably. So the button is divertible and the injection path is healthy — it is the gesture-mode claim that fails.

## Expected

`gesture_buttons=1` with a direction map, and the five directions firing.

## Not a duplicate of

- **#1199** (Lift B031, `GESTURE_BUTTON_CID` hardcoded to `0x00c3`): there `gesture_sources=0` — the source is never found. Here it is found (`=1`) and only the claim fails, so a CID mismatch alone does not explain it.
- **#1262** (macOS, MX Master 3S): different button (wheel/MiddleClick), different platform, and that one is about the global hook path.

## Environment notes

Injection works on this machine once `uinput` is loaded — worth flagging separately, since the shipped udev rule creates `/dev/uinput` via `OPTIONS+="static_node=uinput"` but the `uaccess` tag cannot apply without a real udev device, so on a system where the `uinput` module is not autoloaded the node stays `root:root 0600` and the agent logs `could not install OS input hook` / `failed to create uinput action device`. `sudo modprobe uinput` fixes it; a note in `docs/INSTALL-linux.md` would save people the hunt.

Happy to run any diagnostic build or dump raw HID++ traffic from this device.

Start at the openlogi_device::session::gesture agent entry point and reproduce the supplied TOML gesture mapping on the MX Master 3, checking why the discovered gesture source produces zero gesture buttons. Done means the capture log reports gesture_buttons=1 and all five directions fire; the uinput setup and docs/INSTALL-linux.md note are a separate concern.

Written by the indexing model from the issue text.