Fix snap overlay showing on wrong monitor in multi-monitor setups

[jpenberthy]

Summary

• Bug: On multi-monitor setups, when Ctrl+dragging a window to snap it, the snap overlay grid would show on the wrong monitor (typically only one monitor) instead of following the cursor to the monitor being dragged to.
• Root cause: Each monitor creates its own WindowSnapper instance, but the #onWindowMoved handler never checked if the pointer was within its monitor's bounds. This meant overlays on other monitors would stay visible or activate incorrectly.
• Fix: Added a pointer bounds check in #onWindowMoved that hides the overlay and cancels highlights when the pointer leaves a snapper's monitor area. Also properly hides the container when showRegions is false (previously the else branch was missing, so the container would stay visible even after the modifier key was released).

Details

The change is scoped to #onWindowMoved in window-snapper.js:

1. After reading the pointer position, check if it falls within this snapper's container bounds (i.e., the monitor's work area).
2. If out of bounds: hide the container, cancel the snapping operation's highlights, trigger a repaint, and return early.
3. If in bounds: proceed with the existing onMotion logic, but now also hide the container when showRegions becomes false (the missing else branch).

This ensures that only the monitor under the cursor shows the snap grid overlay, and the overlay properly disappears when the modifier key is released.

Test plan

• On a multi-monitor setup, Ctrl+drag a window across monitors and verify the snap overlay only appears on the monitor under the cursor
• Verify the overlay disappears from the previous monitor when dragging to a new one
• Verify snapping still works correctly on single-monitor setups
• Verify the overlay disappears when releasing the Ctrl key while dragging

🤖 Generated with Claude Code