Desktop-integration tests on a nested/headless compositor

[jonocodes]

Context

Every focus/enumeration test today mocks the compositor (FakeFocusBackend, monkeypatched gdbus/xdotool). Nothing exercises the extension ↔ real-compositor boundary, which is why the get_window_actors receiver bug (e166242) — the running-windows list silently empty since stage 2 (#126) — passed every test and only surfaced on a live GNOME 50 session. This is the "drive real windows across real apps" tier.

Ask

Stand up a headless/nested compositor test job that loads the real extension and drives real windows:

• GNOME path: dbus-run-session -- gnome-shell --nested --wayland under a virtual display; enable deckd-focus@local.
• (Later) generic/KWin path: a lightweight compositor (sway/labwc/weston) for the KWin-script backend (KDE-Wayland focus backend (KWin) #31).

Closed-loop assertions this unlocks:

• Open two real windows (e.g. two foot/xterm); assert ListWindows returns both with sane titles + stable window_ids.
• Call RaiseWindow(<unfocused id>); assert GetActiveWindow now reports that window — a genuine end-to-end for Build stage 3: switch on tap — raise-window dispatch #127's raise-on-tap.
• Enumeration of a closed window drops from the next snapshot (prune-on-unmanaging).

Constraints

• Not on the blocking PR gate — nested GNOME has startup races, focus-timing quirks, and version-specific API drift; budget for occasional flakiness. Run as a nightly / opt-in desktop-integration workflow.
• Skip cleanly where no compositor is available (macOS, headless CI without the harness).
• Wire into just (e.g. just test-desktop) alongside the existing recipes.

Tier B of the desktop-integration testing plan (companion to #129, #130). This is the tier that would have caught the stage-2 regression. Discussion in #127.