test(linux): verify the KWin script against the live Plasma session

The KWin JavaScript had never been executed. It is now.

A probe script was loaded into the running Plasma 6.6.6 compositor, which
reported:

    js: PROBE: activated resourceClass=org.kde.konsole resourceName=konsole
             caption=... internalId={6866aecf-...} pid=4147
    js: PROBE: activated resourceClass=Spotify resourceName=spotify
             caption=... internalId={c99b88b4-...} pid=74378

The probe was unloaded immediately afterwards and `isScriptLoaded` confirmed
`false`.

**This proved one thing I had wrong.** The file asserted that "KWin does not
expose the PID to scripts, so resolution happens on the Rust side from
resource_class." It does expose it — `pid=4147` for Konsole, `pid=74378` for
Spotify. The payload now carries it, and the daemon can resolve
`/proc/<pid>/exe` directly instead of inferring an application from its
resource class. Inferring from `resourceClass` would have been a guess, and a
wrong guess blocks the wrong application.

Also confirmed: `workspace.windowActivated` exists and fires on real window
changes, and `resourceClass`, `resourceName`, `caption` and `internalId` are all
readable from a script.

**Still unverified, and stated as such in the module:** the D-Bus leg — whether
`callDBus` from inside the script reaches an exported daemon interface. That half
is ordinary Rust and needs no compositor, so it is exercised by an integration
test rather than by touching a live session again.

Also records ADR-6 as accepted: the owner chose **egui** for the block screen,
so the UI toolkit is no longer a blocker. Reasoning is in the ADR, including the
licence entanglement — Slint is GPL-3.0, which is why ADR-17 sits upstream of
this decision.

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/DECISIONS.md

@@ -27,7 +27,7 @@ which parts to trust.
 | [3](#adr-3) | Event-driven with `next_wakeup`, never polling | Accepted |
 | [4](#adr-4) | SQLite via rusqlite, in its own crate | Accepted, one trade-off open |
 | [5](#adr-5) | uniffi for core-to-Kotlin bindings | Proposed |
-| [6](#adr-6) | Desktop UI toolkit — Slint vs egui | **Proposed, needs owner** |
+| [6](#adr-6) | Desktop UI toolkit — egui | **Accepted** |
 | [7](#adr-7) | Desktop website blocking mechanism | **Accepted — owner chose extension** |
 | [8](#adr-8) | Lock levels and explicit opt-in | Accepted |
 | [9](#adr-9) | Monotonic clock for all lock timers | Accepted |
@@ -169,29 +169,41 @@ to commit, and the measurement belongs to M3-Android.
 ---
 
 <a id="adr-6"></a>
-## ADR-6: Desktop UI toolkit — Slint vs egui
+## ADR-6: Desktop UI toolkit — egui
 
-**Status:** **Proposed — awaiting the owner's decision**
+**Status:** Accepted (the owner chose egui, 2026-10-01)
 
 **Context.** Section 3 requires the toolkit to be chosen on a measured
 size/RAM comparison, and says explicitly to ask.
 
-**Decision.** Not yet made.
+**Decision.** **egui**, licensed MIT OR Apache-2.0.
 
-**What is already settled by measurement-independent constraints:**
+**Why egui.**
 
-- **Slint is GPL-3.0 or commercial.** For a project intended to be published,
-  the permissive alternatives are the safer default. If the size comparison comes
-  out close, licensing should decide it.
-- Either way the daemon must stay under 5 MB stripped, and the UI must not hold a
-  GL context resident while idle.
+- **The licence decides part of it.** Slint is GPL-3.0 or commercial, so choosing
+  it would force the project under copyleft or require a paid licence. The owner
+  has left the project licence open (ADR-17), so this is a real constraint
+  rather than a formality — and it is why ADR-17 is upstream of this decision.
+- **The budget is adequate.** 2.9 MB of the 5 MB stripped daemon budget remained
+  after storage (1.364 MB) and the D-Bus/X11 backends (2.237 MB) were linked in.
+  A block screen is text and a countdown; it does not need more.
+- **Idle cost is the deciding factor.** The block window is launched on demand and
+  exits when the block lifts, so what matters most is that *nothing* holds a
+  graphics context while idle. egui lets the window own its context for its
+  whole (short) life without the daemon ever touching one.
 
-**What still needs measuring:** stripped binary size for a minimal window, idle
-RSS, dependency count and compile time, and behaviour on KDE Plasma 6 Wayland
-specifically — this project must work on KDE, so winit/Slint quirks on that
-compositor matter more than generic Wayland support.
+**What this does not decide.** The measurement the section asks for is still worth
+doing — it is recorded in `PERF.md` — but it is now confirmatory rather than
+decisive.
 
-Recorded rather than decided because section 3 says to ask.
+**Constraints that apply to whatever is built**
+
+- The block screen shows text, a countdown, and one always-present link. No
+  animation beyond a short fade (motion reads as agitation in this context, and
+  costs idle wakeups).
+- Accent colour is reserved exclusively for the "How to turn this off" link, so
+  the one thing a blocked user needs is the only coloured element on screen.
+- No red, and no shaming copy.
 
 ---