Spike: KDE-Wayland active-window detection (focus watcher) #30

What to build

Investigate the most stable mechanism for getting the focused window on KDE Plasma (Wayland), in the same shape as the existing GNOME spike (#2 / docs/SPIKES.md). Candidate paths to evaluate:

• org.kde.KWin D-Bus interface — does it expose the active client / caption directly?
• A KWin script (analogous to the GNOME Shell extension deckd-focus@local) publishing the active window over a session D-Bus name like org.deckd.Focus (so the daemon's KdeFocusBackend can re-use the same wire shape as the GNOME backend).
• wlr-foreign-toplevel-management-unstable-v1 Wayland protocol — does KWin implement it? wlroots compositors do; KWin almost certainly does not, but confirm.
• Hyprland / Sway / other wlroots compositors if relevant — note whether one wlroots backend could double-cover the family, but the deliverable of this spike is just KDE/KWin.

Pick one path, record the decision + evidence in docs/SPIKES.md. The output should be concrete enough that a follow-up implementation ticket can be written against it without re-investigation: chosen API, the D-Bus name / object path / method shape the KWin script should expose, install/enable steps for the script on a fresh KDE box, and any permissions / Wayland gotchas.

Acceptance criteria

• Each candidate above is evaluated and recorded as viable / rejected with a one-line reason.
• A clear recommendation is reached (one path), with the shape the daemon-side KdeFocusBackend should call (gdbus invocation or Wayland client) noted.
• docs/SPIKES.md updated with a new "KDE-Wayland active-window detection" section parallel to the GNOME spike entry, OR a new spike file linked from it.
• If a throwaway KWin script or gdbus snippet is used during investigation, the minimal reproducible snippet is committed under packaging/ or scripts/ so it can be referenced by the implementation ticket.

Blocked by

• None — can start immediately.