Dear Maintainer,

kwin_wayland crashes reliably when active outputs are hot-removed, e.g.
when unplugging a Thunderbolt dock that drives the enabled displays. On
Wayland this takes down the entire session (every client loses its
compositor connection), so all unsaved work in the session is lost and
the user ends up on a black screen.

Reproducibility here: 2 out of 2 dock unplugs since June crashed the
compositor within one second (2026-06-24 08:44, 2026-07-21 12:11).
Setup: Lenovo ThinkPad TB4 Dock (40B0), three DisplayPort MST monitors,
internal panel disabled while docked - so the unplug removes all
enabled outputs at once. Intel Raptor Lake iGPU (i915), kernel
6.12.95+deb13 at the time of the incidents, Plasma 6.3.6 on Wayland.

Journal signature (identical in both incidents):

  12:11:05 kernel: thunderbolt 1-1: device disconnected
  12:11:06 kwin_wayland_wrapper: KCrash: Application 'kwin_wayland'
           crashing... crashRecursionCounter = 2
  12:11:06 kwin_wayland_wrapper: kwin_wayland_drm: atomic commit
           failed: Bad file descriptor
  (all Wayland clients then report "The Wayland connection broke.
   Did the Wayland compositor die?")

This is upstream KDE bug 495702 (17 duplicates): since the layer-shell
change in kwin 6.2, Workspace::outputRemoved() can trigger
activateNextWindow(), which may set the active output to the output
that is just being removed, leaving Workspace with a dangling pointer.
Duplicate 511230 describes exactly this Thunderbolt dock scenario.

Consistent with that diagnosis, the crash is avoidable by not removing
an active output: if the external outputs are disabled and the internal
panel is re-enabled via kscreen-doctor *before* the cable is pulled,
no crash occurs. I have used that as a workaround since 2026-07-22,
most recently on 2026-07-29/30, with no further incidents - which
supports output removal, rather than the Thunderbolt disconnect as
such, being the trigger.

Fixed upstream by moving the active-output cleanup after the
outputRemoved() signal:

  master:      5aa070d5f4a4c0ce1802aa94eec6ebf9bc9edca9
  Plasma/6.4:  63edb977e99a860a5a167e210e6222a24115c593
               (released in Plasma 6.4.6 and 6.5.1)

The 6.3 series is end-of-line upstream, so trixie will not receive this
fix through any 6.3.x release. The code change itself is 6 lines in
src/workspace.cpp (plus an autotest). I verified that the Plasma/6.4
cherry-pick applies cleanly to the 6.3.6 source, offsets only, no fuzz:

  Hunk #1 succeeded at 1229 (offset 63 lines).
  Hunk #2 succeeded at 2176 (offset 92 lines).

Please consider cherry-picking this for a trixie point release. The
patch (the upstream Plasma/6.4 commit, applies as-is) is included
inline below.

For transparency: the machine runs MX Linux 25's rebuild of this exact
Debian source (4:6.3.6-1mx25); the code is unmodified 4:6.3.6-1 in the
affected paths. I have not attached a backtrace, since the crash is
already identified upstream with a released fix, but I am happy to
provide one from a controlled reproduction against the Debian build if
that would be useful.