Engine: stop waiting on a launcher window that does not answer

[hanthor]

This fixes the window-slot item in #257.

Problem

serve::forward locks the window slot and awaits WindowLink::push with no time limit. If a launcher window is alive but wedged, every request that needs the window (toggle, show, hide, HUDs, dmenu, deeplinks, launches) waits on that lock until the daemon restarts. Only the CLI had a timeout (10 s).

Change

• Engine (crates/compass/src/serve.rs): forward now goes through forward_within with WINDOW_ANSWER_TIMEOUT = 30 s. On timeout it answers with an error that names the wait.
• Why 30 s: the limit bounds a stuck window, not a slow one. A launcher's first Show waits on its renderer, and on a machine without a GPU that takes seconds; it took about 5 s on the wlroots CI runner. The first push used 5 s and failed two Sway tests for exactly this reason.
• The link is kept on timeout. The window may only be busy, and dropping the link would leave the launcher undriven until it restarts, because the UI does not reattach.
• Late answers (crates/compass-ipc/src/transport.rs): a window still answers the command the engine gave up on, in order and before the next one. WindowLink::push now skips answers older than its own command id, instead of failing with MismatchedResponse and getting the window dropped. The new # Cancellation doc section explains this. Framed I/O is cancel-safe, so an abandoned write is finished by the next send.
• No effect on dmenu: every pushed command is answered as soon as the window acts on it. The dmenu choice is awaited outside the push.

Tests

• compass-ipc, a_push_given_up_on_does_not_steal_the_next_ones_answer: the first push is dropped after 100 ms, the window then answers it late, and the next push reads its own answer. This test fails with the skip removed (control run).
• compass, window::tests::the_engine_stops_waiting_on_a_slow_window_and_keeps_it: runs through the real bridge. forward_within times out with an error, the slot still holds the link, and after the UI catches up, forward(Hide) is acknowledged.
• wlroots_engine on local headless Sway: all 16 pass with 30 s. With the limit forced to 200 ms, the two tests that failed in CI fail the same way, which confirms the cause.
• cargo test -p compass-ipc -p compass passes in full; cargo clippy -p compass-ipc -p compass --all-targets -D warnings is clean; cargo doc with -D warnings is clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UtGVEzDmYTdpsuEQErmmLn

[hanthor-hive-agent]

Looks correct to me. forward_within bounds the slot lock and returns an actionable error on timeout (crates/compass/src/serve.rs:2572-2589) without discarding a live window link. The correlation loop then consumes only older late replies before requiring the new command's exact ID (crates/compass-ipc/src/transport.rs:302-328), matching the serialized bridge and the added end-to-end coverage.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.88