Preserve relative window position when moving to another display

[YuriNachos]

Summary

• Preserve a window's relative position (not just its size) when moving to another display with the attemptMatchOnNextPrevDisplay opt-in enabled and no Rectangle snap action to replay.
• A window at the right-third / centered / etc. now keeps that relative spot on the destination screen instead of jumping to the center. The window's rect is mapped proportionally between the source and destination visibleFrames and clamped inside the destination.
• Applies identically to next/previous-display and specific-display (display 1/2/3) moves.
• Opt-in only: users who never enabled attemptMatchOnNextPrevDisplay see no change.

Root cause

NextPrevDisplayCalculation.calculate (and SpecificDisplayCalculation.calculate) only preserved position by replaying lastAction. With the opt-in ON but no replayable lastAction (a manually positioned window), execution fell through to calculateRect, whose override returns centerCalculation — so the window was centered regardless of the opt-in.

Fix

In the fall-through case (opt-in ON, no replayable snap), map the window's current rect proportionally from the source screen's adjustedVisibleFrame to the destination screen's adjustedVisibleFrame, preserving its relative position and size as fractions of the source frame, then clamp inside the destination. Shared by both call sites via a single NextPrevDisplayCalculation.relativePositionedRect(window:source:destination:) helper. Degenerate source frames return the window unchanged.

Testing

xcodebuild test -project Rectangle.xcodeproj -scheme Rectangle -destination 'platform=macOS'

• NextPrevDisplayMappingTests: 4 pure-geometry tests covering right-third mapping, centered-quarter mapping, destination-overflow clamp, and identity. All pass.
• Full suite: 209 tests, 21 pre-existing failures in ActiveSideSplitRatiosCooperativeTests / HalfSplitCornerCalculationTests (unchanged baseline — these pre-date this PR, in-flight cooperative-resize / corner-calc work). No new failures.
• Multi-display end-to-end could not be exercised on the single-display build host; the proportional mapping is covered exhaustively by the unit tests above, and the two call sites are minimal and structurally identical.

AI assistance

This PR was prepared with AI assistance; the approach, tests, and verification were reviewed by the contributor.

Closes #1723

[YuriNachos]

One practical note on this PR: the Build workflow is still marked 'waiting for approval to run', so the checks haven't actually executed on this branch yet. Whenever you're working through the queue, approving that run would let it build — and if anything else would save you time, whether that's a specific display setup to test the relative-position behavior on or further changes to the diff, I'm glad to handle that part. No rush from my side; I just don't want it sitting invisible.

[rxhanson]

Great, thanks! Good point on the workflow approval, and thanks for your patience :)