Let a repeated Maximize restore the window's previous size and position (opt-in)

[X-Wei]

Summary

Adds an opt-in mode in which running Maximize (or Almost Maximize) again on a window Rectangle has just maximized moves it back to the size and position it had right before, so the shortcut toggles between maximized and the previous frame — the way toggling maximize works on KDE.

Today repeating Maximize on an already-maximized window does nothing, and getting the window back means the Restore shortcut, which also undoes every other Rectangle action since you last placed the window. This keeps Maximize and Restore as they are and only adds "press again to go back", behind a single default.

Off by default (repeatedMaximizeRestoresPrevious); nothing changes unless it is enabled.

Related: discussion #894 (requested there; you implemented it in Rectangle Pro). This is the narrow free-Rectangle version — no new shortcut, one self-contained type, one default. Same shape as #1824.

Behavior when enabled

• Maximize on a window Rectangle just maximized → the window returns to its previous frame. Maximize again → maximized again. (Same for Almost Maximize.)
• Only the same action repeated restores: Maximize then Almost Maximize (or the reverse) switches between the two, as today.
• A window maximized by something else, or moved/resized between the two presses, is maximized as usual — the previous frame is used only when Maximize was the last thing Rectangle did to the window and it has not moved since.
• Restoring reuses the Restore action's semantics (clears the window's last-action history; leaves the Restore rect untouched).
• With the repeated-command setting on "Cycle through displays", the restore takes precedence over display cycling for these two actions.
• Works from the shortcut, the menu bar and the URL scheme.

How it works

• The frame is captured in WindowHistory.preMaximizeRects whenever Maximize / Almost Maximize runs.
• The repeat is recognized from the window history exactly like the title-bar double-click restore (TitleBarManager): the window's last action is the same action and it has not moved since. No new geometry or heuristics.
• All the decision logic lives in one new type, RepeatedMaximizeRestore, consulted in WindowManager.execute (and in the display-cycling shortcut path).

Docs / Tests

• Documented in TerminalCommands.md, and exposed as a checkbox at the bottom of the General → Extras popover (same place as Let half actions preserve the window's size on the other axis (opt-in) #1824; title and tooltip registered in Main.xcstrings).
• 7 unit tests (RepeatedMaximizeRestoreTests); the full suite is green.

I'm happy to drop the checkbox and keep it Terminal-only if you'd prefer, like some of the other hidden defaults.

[rxhanson]

Thanks for taking this one on. Would you mind keeping all of the Maximize logic within the MaximizeCalculation, instead of in the WindowManager? Ideally we want to keep execute in the WindowManager as free from special cases for specific window actions as possible.

[X-Wei]

Done — all of the logic lives in the calculations now, and WindowManager is back to a zero diff against main.

• MaximizeCalculation and AlmostMaximizeCalculation each got a one-line calculate(_:) override that consults RepeatedMaximizeRestore first and otherwise falls through to super.
• It has to sit in calculate(_:) rather than calculateRect(_:): NextPrevDisplayCalculation calls maximizeCalculation.calculateRect(_:) directly for the auto-maximize path, and that one shouldn't turn into a restore.
• The restore is returned as a regular calculation result reported as .restore, instead of setting the frame directly. So it goes through the usual pipeline, gets no gaps, and because the window's last action is then a restore, the next execution of the shortcut maximizes it again, calculated from scratch rather than reusing an older frame.
• The one thing left outside the calculation is a one-line guard in ShortcutManager, so that the restore wins over display cycling when the repeated-command setting is "Cycle through displays". Happy to drop that as well if you'd rather leave that path alone.

Tests went from 7 to 13 cases and the full suite is green. Also rebased onto current main.