[win] Fix windows never receiving a mouseup event after moving/resizing

[ckaiser]

Fixes #aseprite/5449 and potentially a few other edge cases and event weirdness. Inspired by the solution used by Qt.

[dacap]

I wasn't able to test this yet, but I'm not sure about this solution, probably we could generate a WindowLeave and then a WindowEnter event? similar to aseprite/aseprite@c31aadae9 I need to give a try on Windows yet to check the bug it fixes first.

[ckaiser]

It feels more like something that should be handled at the LAF level transparently, since it's a platform quirk combined with a quirk of how we handle mouse input (storing the keys based on events instead of providing ways to query the mouse), but I'm open to suggestions on a different way to go about it

[dacap]

Just testing on Linux. Pressing all mouse buttons (left/middle/right) on the left window, then Alt+tab to the right window, and release those buttons, laf sends a mouse up for each button to the left window and the capture is lost:

2026-05-28.08-23-29.mp4

I'll test this on Windows later, but I think with this PR we can match the Linux behavior.

[dacap]

After reviewing the original bug it looks like a specific problem of borderless windows with custom hit areas (title bar, etc), which is the case of Aseprite children windows. And only for the left mouse button (which is the one that triggers the window dragging/resizing).

I've found that WM_EXITSIZEMOVE/WM_EXITSIZEMOVE is not received if we just click the window title bar (without moving the mouse) and it produces the same issue if we don't generate a MouseUp message from other place.

I've created a new PR #191 which should be enough but feel free to give a try and test it (anyway I'll merge it ASAP for tomorrow release).