fix(app): drag the splash by hand to avoid the hitch on release

[coldhighsun]

Summary

• Dragging the startup splash and releasing the mouse made it stutter. The splash used Window.DragMove, whose Win32 modal move loop is the suspected cause.
• The splash is now dragged with mouse capture. SplashDragTracker (pure, device pixels) computes the position, and the window is moved with one SetWindowPos per mouse event.
• A drag in progress is re-anchored from the real window bounds when the window changes DPI. A failed capture or bounds read does not leave the mouse captured, and only the window's own LostMouseCapture ends the drag.
• Shared user32 declarations (POINT/RECT, GetCursorPos, GetWindowRect, SetWindowPos, SWP_* flags) move into Infrastructure/WindowNativeMethods; WindowMaximizeHelper now uses its structs. CLAUDE.md is updated for both.

Not verified

• The cause of the hitch is a hypothesis; it has not been measured, so the fix needs a manual check on a real run.
• The new SplashDragTrackerTests were not compiled or run (NuGet restore of the test project failed locally). The app project builds with --no-restore.
• Dragging across monitors with different DPI and main-window maximize (touched by the WindowMaximizeHelper refactor) were not exercised.

Test plan

• dotnet test tests/ManagedDrive.Tests --filter "FullyQualifiedName~SplashDragTracker"
• Start with several auto-mount disks, drag the splash and release: no stutter, animations keep running
• Drag the splash to a monitor with a different DPI: it stays under the cursor
• Maximize and restore the main window

[codecov]

Codecov Report

❌ Patch coverage is 21.27660% with 37 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/ManagedDrive.App/Views/SplashWindow.xaml.cs	0.00%	37 Missing ⚠️

📢 Thoughts on this report? Let us know!