fix: report mouse drags in button-motion (1002) tracking mode

[Patrick-Kappen]

Problem

handle_cursor_moved only reports drag motion to the backend when the terminal is in MOUSE_MOTION (1003) mode. Applications that request button-motion tracking (1002) — most notably tmux with set -g mouse on — get the press and release reports but never the drag in between, while the widget simultaneously runs its own SelectUpdate selection.

The result with tmux: tmux sees click+release with no motion (so no copy-mode drag selection), while the widget paints its own selection overlay on top — two selection systems fighting over the same drag.

Fix

Check MOUSE_DRAG | MOUSE_MOTION when deciding whether to report a drag, matching how press/release already use the umbrella MOUSE_MODE (which includes all three tracking modes). Widget-side selection still applies when neither motion mode is active (plain 1000 click-only tracking).

Includes a regression test (reports_drag_when_dragged_in_mouse_drag_mode).

Repro

1. run an app embedding the widget and attach to tmux -L test with set -g mouse on
2. drag-select some text in a pane
3. before: widget-local selection appears and tmux never enters copy-mode; double-click flashes tmux word-select while the widget selects independently
4. after: drags are reported and tmux handles selection natively, as in other terminals