feat(server)!: give mouse button events a position, fix X1/X2 and middle-button/hwheel handling

[Greg Lamberson (glamberson)]

Summary

• Fixes ironrdp-server: button mouse PDUs drop their coordinates — clicks land at the stale cursor position for clients that send a button with no preceding MOVE #1466: MouseEvent's button variants were position-less, so From<MousePdu> and From<MouseXPdu> silently discarded the wire PDU's x/y whenever a button flag was set (position only survived for a pure Move). A client that sends a tap as a single button PDU with no preceding Move (confirmed: Windows App on iOS/iPadOS, touch mode) clicks at the stale cursor position rather than where it tapped.
• While fixing that, found two more bugs in the same conversion layer, both confirmed against MS-RDPBCGR: From<MousePdu> never checked MIDDLE_BUTTON_OR_WHEEL or HORIZONTAL_WHEEL, so middle-click and horizontal wheel silently fell through to the Move fallback. From<MouseXPdu> mapped PointerXFlags::BUTTON1/BUTTON2 to Left/Right, but per 2.2.8.1.2.2.4 these are "Extended mouse button 1 (also referred to as button 4)" and "...2 (...button 5)", the X1/X2 side buttons. MouseRelPdu's own sibling From impl already distinguishes these correctly via XBUTTON1/XBUTTON2, so this was an inconsistency, not a deliberate choice.
• Checked FreeRDP, xrdp, KDE krdp, and GNOME Remote Desktop before settling on a shape. All four check explicit MOVE flags rather than falling through on else, all four handle middle button and both wheel flags, none conflate X1/X2 with primary buttons. xrdp's own source has a maintainer comment confirming real clients exercise the HWHEEL gap: "As mstsc does MOUSE not MOUSEX for horizontal scrolling, PTRFLAGS_HWHEEL must be handled here."
• MouseEvent::Button { x, y, button, pressed } replaces the ten position-less LeftPressed/LeftReleased/.../Button5Released variants, scoped to the PDU types that actually carry absolute position (MousePdu, MouseXPdu, ainput::MousePdu, which already carried x/y on every event but never applied it to buttons either). MouseRelPdu gets MouseEvent::ButtonRel { button, pressed } instead, since it only has relative deltas. Both share a new MouseButton enum (Left/Right/Middle/X1/X2). Added MouseEvent::HorizontalScroll to pair with the existing VerticalScroll. Breaking anyway, so MouseEvent and MouseButton are both #[non_exhaustive].
• There's independent, unmerged prior art for the middle-button half of this on branch probakowski/xrdp (commit e924272, ad hoc xrdp-interop debugging, never opened as a PR) that arrived at the same MIDDLE_BUTTON_OR_WHEEL fix. Crediting it here since I found it while researching this.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass.

Notes

Single file, crates/ironrdp-server/src/handler.rs. Grepped the whole workspace for MouseEvent:: usage; this file is the only one that constructs or matches it, no other call sites need updating for this PR. Downstream, I'm updating my own lamco-rdp-input/lamco-rdp-server consumers to the new shape as a follow-up.

[clintcan]

Thanks for running with it, Greg Lamberson (@glamberson) — no problem that you took it; the broader scope you found is exactly why it's better in your hands than a narrow patch from me.

Corroborating from the downstream side (macrdp is where #1466 came from): our vendored fix deliberately scoped to LEFT/RIGHT only (the reported iOS touch-tap, a left-click), but our divergence note explicitly flagged that middle-click and the MouseX (X1/X2) buttons have the same latent coord-drop, left unaddressed — so fixing all the button paths uniformly matches what we'd independently seen, and it's the right call over a per-button patch.

The two extra bugs you folded in (From<MousePdu> skipping MIDDLE_BUTTON_OR_WHEEL/HORIZONTAL_WHEEL, From<MouseXPdu> mapping X1/X2 → Left/Right) are consistent with how brittle that layer is — good catches. Option 2 (position on the button variants, #[non_exhaustive] on MouseEvent) is fine by us as a downstream MouseEvent consumer — we laid out both shapes on #1466 to leave that call to you — and we'll adapt at the pin bump.

Happy to validate the button behavior end-to-end on macrdp (mstsc + Windows App, incl. middle / X-buttons) once the shape settles, if a real-client check helps.