[Feature]: KWin/Plasma native-Wayland frontmost-window backend

### Pre-flight checklist

- [x] I searched existing issues and the Roadmap, and this isn't already tracked.

### Problem / motivation

#191 added Wayland-native frontmost-window backends for wlroots compositors (`zwlr_foreign_toplevel_management_v1`) and GNOME Shell (companion D-Bus extension), with X11/XWayland as the universal fallback. KDE Plasma/KWin has neither: it isn't wlroots-based, and there's no KWin-side backend equivalent to the GNOME extension. So `detect_session_kind()` picks Wayland, both Wayland candidates fail to initialize, and `frontmost_bundle_id()` falls through to the X11 backend — which only sees XWayland windows. Native-Wayland KDE apps (anything not running under XWayland) report `None`, so per-app profiles silently don't fire for them.

This matches real user reports: #355 was filed by a KDE Plasma/Wayland user (separate touchpad-grab bug, being fixed in #356), and #191's own compositor-coverage table lists "KDE/KWin, others" as X11/XWayland-fallback-only, a known gap at merge time.

### Proposed solution

Add a `FrontmostSource` candidate for KWin, following the same pattern as the two existing Wayland backends in `crates/openlogi-hook/src/linux.rs`. KWin has no public Wayland protocol for this either, so the practical options are:

- A KWin script (using the KWin scripting API's `workspace.activeWindow`) that exports the focused window's resource class over a D-Bus service, mirroring the GNOME Shell extension's `org.openlogi.Frontmost` approach.
- Or investigate whether KWin's existing `org.kde.KWin` D-Bus interface / `kwin_wayland` already exposes enough (e.g. via `queryWindowInfo` or similar) to avoid shipping a companion script at all.

Whichever backend lands, it should return KWin's native window identifier and slot into `wayland_candidates()` alongside the wlroots and GNOME backends, falling through to X11/XWayland exactly as today when it can't initialize.

### Alternatives considered

- Leave KDE on the X11/XWayland fallback — this is the current behavior, but means per-app profiles don't work for native-Wayland apps on the second-most-common Linux desktop after GNOME.

### Related area(s)

- [x] Per-application profiles
- [x] Other (Linux/KDE Wayland support)

### Additional context

- Wayland backend dispatch: `crates/openlogi-hook/src/linux.rs` (`wayland_candidates()`, `FrontmostSource`)
- Existing GNOME backend for reference: `crates/openlogi-hook/src/linux/gnome_shell.rs` + `crates/openlogi-hook/gnome-shell-extension/`
- Existing wlroots backend for reference: `crates/openlogi-hook/src/linux/wlr_foreign_toplevel.rs`
- Originating PR: #191

Start with wayland_candidates() and FrontmostSource in crates/openlogi-hook/src/linux.rs, then read linux/gnome_shell.rs, the gnome-shell-extension directory, and linux/wlr_foreign_toplevel.rs. Determine the KWin integration approach, and consider the work done when native-Wayland KDE apps provide their window identifier while initialization failures still fall through to X11/XWayland.

Written by the indexing model from the issue text.