Stylus/tablet click (ButtonPress) not registering in desktop (CEF) build when device uses absolute positioning — works in Relative mode, in browser, and with physical mouse

### Describe the Bug
On Linux (Flatpak build), a graphics tablet's pen click does not register in the desktop app's CEF-rendered UI or viewport when OpenTabletDriver is configured in **Absolute** mode (normal tablet-to-screen 1:1 mapping), even though:
- The exact same tablet/pen works correctly in the web version at https://editor.graphite.art/ (in Chromium), also in Absolute mode
- A physical USB mouse clicks normally in the desktop app
- `xdotool click 1` (synthetic XTEST click) also fails to register in the desktop app
- **Switching OpenTabletDriver to Relative mode makes clicking work correctly in the desktop app** — this isolates the bug to something specific about how absolute-positioning tablet devices are handled, since relative mode is otherwise unusable for real drawing (no 1:1 tablet-to-screen mapping)

Cursor **motion** from the tablet works perfectly in Absolute mode in the desktop app — only button press/release events fail to have any effect while in that mode.

### Environment
- OS: Void Linux, X11 (picom compositor, XFCE)
- Graphite: desktop Flatpak build (`art.graphite.Graphite`), downloaded ~July 2026
- Tablet driver: OpenTabletDriver 0.6.7 (Flatpak)
- Tablet: Huion H1161
- GPU: AMD (RADV/Mesa)

### Steps To Reproduce
1. Install OpenTabletDriver via Flatpak, configure tablet in **Absolute mode** ("Artist Mode" preset) with tip bound to Mouse Button: Left
2. Install Graphite via Flatpak
3. Launch Graphite desktop app
4. Attempt to click/draw with the stylus tip on the canvas or any UI button
5. Motion works; the click has no effect
6. Switch OpenTabletDriver to **Relative mode**, click Apply, retest — clicking now works correctly

### Investigation so far
- `xinput test-xi2` confirms the pen's `ButtonPress`/`ButtonRelease` arrive as genuine X11 core-protocol events from the same device (`OpenTabletDriver Virtual Tablet`, XI2 id 19) that generates the working motion events — not routed through the XTEST virtual pointer (id 4)
- `udevadm info` confirms the OTD virtual device is tagged `ID_INPUT_MOUSE=1`
- `libinput list-devices` shows the OTD virtual device's `Capabilities: pointer`, but its `DeviceChanged` XI2 announcement in Absolute mode includes **absolute X/Y valuators plus an XIScrollClass** (relative horizontal/vertical scroll valuators) — attributes a plain mouse does not have
- A real physical USB mouse (no absolute valuators, no scroll-class) clicks Graphite's UI/canvas without any issue in either mode
- `xdotool click 1` (XTEST-injected click) also fails silently in the desktop app while in Absolute mode
- **Confirmed:** switching the same physical tablet/driver to Relative mode (removing absolute valuators from the device's XI2 announcement) makes clicks work correctly again

This strongly suggests Graphite's CEF-embedded input handling (see #2535, the CEF-based desktop architecture) filters or mis-routes button events specifically from devices that report absolute positioning valuators, rather than a general click-handling bug — since motion, physical mouse clicks, and relative-mode tablet clicks all work fine, and only absolute-mode tablet clicks fail.

### Additional Details
- Toggling **Preferences → Render GUI on CPU** (`disable_ui_acceleration` in `preferences.ron`) fixed an unrelated issue where the GUI failed to render at all, but did not affect this click bug.
- Happy to provide further logs/testing (e.g. `libinput debug-events`, CEF verbose logging flags) if useful for triage.

Start by reproducing the issue with the Graphite desktop Flatpak and compare CEF-based input handling for absolute- and relative-mode tablet events, using the investigation details and #2535 as context. Inspect preferences.ron only as needed to keep disable_ui_acceleration separate from this bug; done means absolute-mode pen ButtonPress and ButtonRelease events work in the UI and viewport without regressing mouse or relative-mode input.

Written by the indexing model from the issue text.