fix(windows): reverse horizontal scroll direction for synthetic wheel input

[palmoni5]

Problem

Two-finger horizontal trackpad pans (and mouse tilt-wheel scrolls) move the page content in the opposite direction inside the WebView. Reported against the Kidush HaChodesh plugin in Otzaria: the same plugin scrolls correctly in a regular browser and in other hosts, so the reversal is on the host side. It was misattributed to RTL documents — it is actually document-independent (deltaX is physical), but horizontal-scrolling plugin content happens to be RTL, which is where it was noticed.

Root cause

The synthetic wheel injection treats both axes with the same sign, but the WM conventions are asymmetric:

Message	Positive data means
WM_MOUSEWHEEL	scroll up (browser deltaY negative)
WM_MOUSEHWHEEL	scroll right (browser deltaX positive)

The Flutter engine mirrors this asymmetry when producing PointerScrollEvent (it negates only the vertical axis on Windows), so the round trip back into WebView2 via SendMouseInput must too. Both horizontal paths were inverted:

• Trackpad (PointerPanZoomUpdate): fingers right produced a positive hwheel → content moved left, opposite the fingers.
• Mouse tilt wheel (PointerScrollEvent): scrollDelta.dx was negated like dy, re-reversing the engine's already-correct sign.

Fix

Sign-only change in the Dart conversion layer (custom_platform_view.dart); the native side keeps passing raw wheel data through:

• _sendTrackpadScrollDelta negates dx so the content follows the fingers — this also covers the synthetic fling, which shares the path.
• The PointerScrollEvent path forwards dx unnegated, reproducing the original native delta.

Tests

Updated the two tests that pinned the reversed sign and added an explicit direction test per input path (trackpad + wheel), documenting the WM_MOUSEHWHEEL asymmetry so it cannot regress. flutter test test/custom_platform_view_scroll_test.dart: 17/17 pass; flutter analyze clean.