screen-capture.sh was a single non-executable line containing a `slur` typo,
so it never ran and nothing referenced it; rewritten as a working region
capture to ~/Pictures plus clipboard.
xdg-desktop-portal/portals.conf pins the wlr backend for sway, and swaync is
pulled in via graphical-session.target.wants so the portal's
Requisite=graphical-session.target is satisfied (the reason screen sharing
previously never started).
watchdog: covers both observed deadlock flavours -- the loud one that repeats
"Received invalid input AtomicChangeDone at state Discarded", and the silent
one that logs nothing and just never leaves VariantInProgress.
shikane-recover-on-reload.sh (new, previously referenced by sway/config but
never committed): shikanectl reload -> sleep 2 -> watchdog check, falling
back to a service restart when reload cannot recover.
clamshell-mode.sh: documents why the laptop panel is no longer enabled
unconditionally on lid-open, which raced shikane's "External Display" profile
(eDP-1 disabled by design) and produced "Atomic commit failed: Device or
resource busy" churn.
recover-output-after-resume.sh existed to work around the old ThinkPad's
/etc/modprobe.d/i915.conf, which forced PSR2 and the deepest display
C-states; the flip pending across suspend never completed, so every later
commit returned EBUSY and only a full modeset cleared it.
That file is gone and this laptop's iGPU is driven by `xe` (Panther Lake has
no i915 support at all), so the original cause cannot recur. The modeset is
now conditional on the user journal actually reporting "Atomic commit
failed"/"Page-flip failed" within the last 3 minutes.
Unconditional disable/enable + `shikanectl reload` on every resume was itself
a hazard: it is the exact sequence that re-triggers the shikane
VariantInProgress deadlock the watchdog exists to recover from.
hypridle.conf's comment no longer references the deleted i915.conf.