TL;DR

A window that leaves its layout for a while (minimized, hidden with its app, or in native fullscreen, including browser video fullscreen) now comes back to the same place at the same size, in every layout mode, and to the workspace it left.

Refs #520; covers #541, #479 and #511. #504 is already handled by scrolling.preserve_window_sizes.

Problem

A returning window goes through the new-window path, so it is inserted next to the current selection with default sizes. Minimizing (and hiding, which Rift treats as minimizing) also clears the workspace assignment, so the window can come back in whichever workspace is on screen.

Approach

New module layout_engine/engine/departures.rs, called from remove_window_internal and add_window_to_layout:

• When a window leaves, the engine keeps a preview_clone of its workspace's layout system from before the first window that is still away left.
• When a window returns and the workspace has otherwise only lost windows, that copy, minus the windows still away, replaces the current layouts. This restores the exact position and split sizes, whatever order the windows return in.
• If the workspace changed in another way, the window is inserted after the window that preceded it instead of next to the selection.
• A returning window without a workspace goes back to the one it left, and app rules do not move it (the same treatment as a persistence match).
• Adding a window to a layout now reports a layout change, so the windows on screen make room for a returning window at once, and a window returning to a workspace that is not shown is moved off screen instead of staying where it was drawn.

Notes

• Every removal records a departure, not only minimize and fullscreen events: a window on its way to native fullscreen is removed through several paths and can be missing from the window store for a moment. A record is dropped when the window is placed back on its space or its app quits, so a closed window's record stays until then.
• The copies are dropped when the layout settings change; windows away then return after their neighbors.
• A window that returns while another workspace is shown goes to the workspace it left, and the screen does not follow, as macOS leaves the desktop alone when a minimized window is restored from the Dock. Following it could be a separate change if wanted.

Testing

• New unit tests in departures.rs for every layout mode, several windows returning in any order, a resized split after a minimize, the neighbor fallback, the workspace of a minimized window, and the layout pass a returning window asks for. They fail without the change.
• cargo +nightly fmt --all --check, cargo check --locked, cargo test (the only failure, empty_active_space_membership_during_wake_race_does_not_blank_known_active_windows, also fails on main on this machine).
• By hand on macOS 27.0.1, with a small AppKit app that puts one of its three windows into native fullscreen, minimizes it, or hides the app, in bsp, traditional, master_stack, scrolling and stack; hiding an app in one workspace and showing it from another; and video fullscreen in a browser.