fix: never hook a layout the desktop no longer matches (#607)

[mgth]

Fixes #607.

Undock a laptop, put it to sleep, wake it alone: the LBM window shows the laptop screen, but the cursor gets stuck on part of the screen's edge until LBM is stopped. Current.xml still describes the four docked monitors — the daemon is running the docked layout.

What happens

The engine's move_cursor (engine/mod.rs) confines the cursor to the target zone's rectangle with ClipCursor before moving it there. When that zone is a monitor that is no longer attached, Windows clamps the clip to the nearest reachable pixels: the segment of the laptop's edge that bordered the phantom monitor. That is the "middle third" in the report.

How the docked layout reaches the daemon after the desktop has changed has two roots, and the fix closes both, plus a third path found on the way:

1. The daemon hooks whatever it is given. It unhooks itself on WM_DISPLAYCHANGE and relies on the UI to send fresh zones, but nothing checked that the zones it then receives match the desktop. The startup replay of Current.xml has the same exposure: boot undocked after being docked, and the daemon hooks the docked layout until the UI connects.
2. The UI's Starts are not ordered. Around a wake three paths ask for a Start — the reconcile after Resumed, the resume watchdog, the rebuild after DisplayChanged — each with the zones computed at its own moment, then each waits (topology prologue, recovery-file write, pipe) before sending. A Start asked for before the rebuild can reach the daemon after the one asked for after it, and Current.xml records the last one sent — which is what the report shows. And since Enabled is stored per layout, a rebuild into a layout the user turned off sent nothing at all, leaving the daemon with whatever it last had.
3. A Run behind a Load that did not parse hooked the previous layout, with the hook kept up for the swap. The file replay already refused that; the live frame did not.

Change

Daemon

• Shared::monitors_now — the attached monitor rectangles, asked at Run time. Windows enumerates them with EnumDisplayMonitors in the same per-monitor-DPI-aware coordinates the UI computes zone bounds in; Linux answers "unknown", which leaves the layout unjudged, exactly as before. A function pointer so tests can bring a desktop of their own.
• daemon::run declines when a main zone overlaps no attached display (phantom_zones). Overlap, not equality, so a mode change the UI has not rebuilt for yet is not a refusal — a refused Run is LBM not working. The refusal is spoken on the wire as a new RunRefused event with the reason (no display under Dock), and takes the hook down if a Load+Run frame had kept it up for the swap. The virtual-layout refusal goes through the same path.
• receive_message no longer honours a Run behind a failed Load, and load_layout takes the hook down on a failed parse when the frame had kept it up.
• Rect::intersects.

UI

• LatestRequestGate: every Start, live-preview frame, Stop and Quit takes a ticket before anything is awaited; when its turn to send comes, a Start whose ticket is no longer the newest is dropped. A Stop always lands, and queues behind a send in progress rather than overtaking it.
• EngineController.ReconcileFreshLayoutAsync (was StartIfEnabledAsync): a rebuilt layout the user turned off now sends an explicit Stop instead of nothing — which also outranks any Start still in flight.
• RunRefused is parsed, shown by the location control, and traced in daemon-events.log like every other event; older UIs reject it as unknown, per the contract. Golden corpus and wire-contract/README.md updated.

What is and is not established

The clip-to-phantom-monitor mechanism and the three paths above are established from the code. The report's timeline is not fully explained: Running arrives 5.3 s after Resumed and no frame reached the daemon before the DisplayChanged at 43.66 s. The daemon-side check makes the outcome the same whichever path delivered the stale layout, which is why it is the primary fix; the UI ordering removes the race itself. Not reproduced on hardware — this machine is Linux, where monitors_now is unknown; the Windows side was cross-checked with cargo check --target x86_64-pc-windows-gnu.

Ported onto the rust/ workspace (2026-09-16)

Master moved the hook to rust/crates/lbm-hook (with Rect in lbm-geom and the protocol in lbm-ipc) while this was open. The moved files were byte-identical to the ones this branch edited, so the two commits reapplied unchanged at their new paths. One commit was added: the Rust agent now reads the hook's events through lbm_ipc::client, and its reconciler already had a HookEvent::RunRefused — the parser and the two mappings behind it did not, which the client golden caught. The reconciler treats it as the frontend's to show, with Stopped remaining what it reasons on.

Tests

• Whole rust/ workspace green, cargo fmt --check and cargo clippy --all-targets -- -D warnings clean, the latter also cross-checked for x86_64-pc-windows-gnu on lbm-hook and lbm-ipc.
• Rust, hook (110 lib + 27 integration): a layout for an unplugged display is not hooked while the layout itself loads; a matching layout is; an unknown desktop leaves it unjudged; a stale Load+Run over a hooked engine takes the hook down; phantom_zones on overlap, reshaped desktops, and shared borders; a Run behind a failed Load neither re-hooks nor leaves the hook up. Goldens regenerated with the new event.
• C# (343 DisplayLayout, 355 Ui.Avalonia): LatestRequestGate — only the newest lands, the old-layout Start claimed first but served second is dropped, a Stop supersedes a Start still on its way and always lands, a send in progress is followed never overtaken; ReconcileFreshLayoutAsync stops a disabled layout and leaves a missing one alone; RunRefused parsed, required in the golden corpus, and shown with its reason.

🤖 Generated with Claude Code