fix(input): stop clicks passing through occluding windows

[BluntEXE]

Summary

The phone accepted clicks and hovers even when a different Dalamud window sat on top of it. Every row, button, and gesture used raw ImGui rect checks that never asked which window ImGui considers hovered this frame, so clicks passed straight through a plugin window drawn on top.

Root cause

UiInteract.Hover() already existed as the shared hit-test primitive most of the app calls through, but it never checked window ownership. PhoneWindow.Draw() now records ImGui.IsWindowHovered(ImGuiHoveredFlags.ChildWindows) once per frame; Hover() and Click() both gate on that. Click() also re-checks it directly, so a call site with its own hover test still can't fire an action while another window occludes the phone.

The same gap showed up outside UiInteract in a few shared components that predate it or duplicate its logic locally: Marquee's auto-hover variants, DragTracker.Begin (Control Center's swipe, Notification Center's swipe-to-dismiss), HomeInteractionController's tap and magnify hover, and the Games framework's RestartButton/Button. Fixed once in each, which covers every caller.

Per-area

• UiInteract: window-hover gate, a 3-arg Hover overload for the existing clip parameter, and Click() hardened as a backstop for callers with a raw hover test.
• PhoneWindow: records window-hover state once per frame before any hit test runs.
• Home screen: tile taps, magnify hover, page dots/arrows, edit-mode Add/Done, folder contents, widget gallery and size menu.
• Control Center: tile press/drag-start, swipe-open/dismiss, top-band cursor.
• Dynamic Island, camera controls, notification center and banners, chat bubbles/transcript/menu, roughly twenty mini-games' board input, and every remaining Marquee/hover call site in the app. Same pattern each time.
• Games/Flow: kept a plain bounds check for the in-progress drag path. Routing it through UiInteract.Hover let DragScrollHost's scroll-vs-tap heuristic set InputBlocked mid-drag and freeze the pipe being drawn. Only the initiating press is gated now, matching the pattern already used for the home screen's drag continuation and Solitaire's card grab.

Test plan

• dotnet build clean after each change
• Verified in-game via full plugin reload across Home, Control Center, Dynamic Island, Camera, Notifications, Message/social apps, and the affected mini-games, with a Dalamud window held on top

[XeldarAlz]

Built clean on bb1a4de (dotnet build -c Release, 0 errors, 4 pre-existing NU1902 warnings) and 143/143 tests pass. Not verified in-game, so the runtime findings below come from reading the code.

The window-hover gate itself is the right fix. The problem is routing it through UiInteract.Hover, which also drags in InputBlocked and MouseOverOverlay: the overlays that raise those flags for everyone else now block themselves. Four blocking spots inline.