fix: stop the touchscreen and touchpad being grabbed as controller touchpads

[dahui]

Summary

Fixes #18 — opening the drawer killed the machine's own touchscreen and touchpad
system-wide, while a stylus kept working.

classifyDevice treated any device exposing ABS_MT_POSITION_X with no gamepad
buttons as a PlayStation controller touchpad and EVIOCGRAB-ed it whenever the drawer
was shown. The Z13's touchpad and touchscreen both match that test, so opening the
drawer took them away from the compositor entirely. The stylus survived only because it
reports pressure and tilt instead of multitouch slots — exactly the asymmetry in the
report — and Esc restored input because dismissing ungrabs.

This is not the GNOME overlay backend, which is where the issue thread first pointed it.
The grab is backend-independent, so @Pandry's KDE report is the same bug. It also only
bites users who can open those device nodes: stock udev grants the session user an ACL
on joysticks but not on touch devices, so input-group members hit it and most people
never do.

Changes

• classify now requires a sibling gamepad. A multitouch device is only grab-only
  when a gamepad from the same physical controller is already tracked. Every input node a
  HID driver creates inherits bus/vendor/product from the parent hid_device, so a
  DualSense touchpad always matches its own gamepad node, while 0b05:1a30 (ASUS
  touchpad) and 04f3:43c7 (ELAN panel) never can. PS touchpad suppression is preserved.
• INPUT_PROP_DIRECT devices are rejected outright — a touchscreen is never a
  controller touchpad. Deliberately not filtering on INPUT_PROP_POINTER or
  INPUT_PROP_BUTTONPAD: the laptop touchpad reports both, and so do PS touchpads.
• uniq / phys disambiguate two controllers of the same model. A refinement only —
  mistaking one DualSense's touchpad for another's still grabs a controller touchpad.
• scan() inspects everything before classifying anything. /dev/input/event*
  enumerates in node order, not device order, and a controller's touchpad routinely comes
  before its gamepad. Unmatched devices are left untracked so the 5s rescan re-evaluates
  them once the controller appears.
• Split classifyDevice into inspect() + a pure classify(). Classification took a
  *evdev.InputDevice and could not be exercised without the hardware in hand; the pure
  function is what makes the tests below possible.
• Troubleshooting entry in docs/installation.md describing the symptom, why only
  some users saw it, and pointing at 1.4.1.

Testing

New internal/gui/gamepad/gamepad_test.go is table-driven off the real capability
sets transcribed from /proc/bus/input/devices on a GZ302EA — Z13 touchpad, ELAN
touchscreen, ELAN stylus — plus DualSense gamepad/touchpad/motion nodes and the Steam
virtual pad. It covers the regression guard that matters: attaching a controller must not
resurrect the bug for the machine's own devices.

Verified before/after against the actual hardware, running as root so every node is
openable (the worst case):

/dev/input/event11  before=GRAB-ONLY  after=ignore  04f3:43c7  ELAN9008:00 04F3:43C7
/dev/input/event5   before=GRAB-ONLY  after=ignore  0b05:1a30  GZ302EA-Keyboard Touchpad
scanned 24 devices, 0 would be grabbed

Checklist

• make build passes
• make lint passes (0 issues.)
• go test ./internal/theme/ -v passes
• Documentation updated if needed

---