Move window to the display under the cursor

[Kiizon]

Closes #1908.

What it does

• Shows the existing cursor screen detection setting in Settings as "Move window to display where cursor is" under Across Display Settings. Previously it only appeared once the hidden default was already on.
• When it's on, a command moves the focused window to its target position on the display under the cursor.
• Fixes the repeat problem from the issue: if the cursor has moved to another display since the window's last command, the next command is treated as a first press on that display, not a repeat. Before, Left, then moving the cursor, then Left again landed on the right half of the old display.
• If the cursor stays on the same display, repeats behave exactly as they do with the setting off.
• Next/Previous Display always count from the window's display.

How

WindowHistory keeps the frame of the display that was under the cursor for each window's last command. WindowManager and ShortcutManager compare it with the display under the cursor now. If the cursor hasn't changed displays, the command works from the window's display, the same as with the setting off. This doesn't depend on the last recorded action, which Rectangle forgets whenever an app adjusts the frame it was given (common when moving across displays).

Tests

• New tests cover: moving to the cursor's display, a cursor display change ending a repeat (for both the cross-display and cycle-sizes modes), repeats still working while the cursor stays put, a repeated walk across displays matching the setting-off behavior even when the app adjusts the window's frame, Next Display counting from the window's display, and the setting being off.
• withExecutionSettings now pins useCursorScreenDetection, so the existing display-cycle test doesn't pick up the machine's own setting.
• Tested manually on two displays with halves and thirds: commands follow the cursor to the other display, and repeating Left with the cursor still walks the window through both halves of both displays, the same as with the setting off.

All 576 tests pass. Note: I built and tested with Xcode 26.0.1, using local-only changes (old app icon, macOS 14 deployment target, no macOS 27 menu API) that aren't part of this PR. It hasn't been built with Xcode 27.

[rxhanson]

Thanks for working on this! The WindowManager has to be refactored before this goes in, unfortunately. I'll post back when it's ready, and I don't foresee it being difficult to accommodate the change.

Some quick background: There are a few files in Rectangle where all logic flows through, and they are the easiest places for changes to accumulate. The WindowManager is the most central, and it simply needs a better architecture to handle many of the changes that have recently gone in and will continue to come in.