Wayland: clipboard, session lock, screencopy, multi-monitor; modularize

Implements the protocols that were blocking srdwm-wayland from being a real
session, plus multi-monitor, and splits the backend into modules. Everything
here was verified by running it against real clients, not just compiled.

Protocols
- wlr-layer-shell + xdg-output: bars/launchers/notifications. xdg-output is
  not optional in practice - without it wofi segfaults rather than
  degrading, since it calls get_xdg_output without null-checking.
- Clipboard: wl_data_device_manager, primary selection, and wlr-data-control.
  Data-control is what `wl-paste --watch cliphist store` needs, as it reads
  the selection without holding focus. Selection focus now follows keyboard
  focus, without which a focused window can neither copy nor paste.
- ext-session-lock: `locked` gates rendering and input. No key is treated as
  a WM binding while locked - the config binds Mod4+Return to spawn a
  terminal, so honouring bindings at a locked screen would defeat the lock.
  The lock is confirmed only after a client-content-free frame has actually
  been presented, never at request time.
- wlr-screencopy (hand-written; smithay ships no helper) for grim/slurp.

Multi-monitor
Every connected connector becomes a head with its own buffers, damage
tracker and page-flip state, matched by CRTC so differing refresh rates
don't gate each other. Outputs are reached through primary_output/output_at/
output_for_wl rather than a single field, which kept the change to ~11 call
sites. Session lock creates one lock surface per output and waits for all of
them, so a second monitor can't still show the desktop when the locker is
told the session is safe. Modes are picked by the PREFERRED flag, not list
order, and CRTCs are never double-assigned.

Bugs found by testing, not review
- Nothing gave a newly-created window Wayland focus: a freshly-opened app
  received no keystrokes and could not paste until clicked.
- Opening a window at a locked screen stole keyboard focus. Caught by
  counting wl_keyboard.enter delivered to a client launched while locked:
  1 before the guard, 0 after. A killed locker correctly leaves it locked.
- Reading back the winit EGL window surface destroyed the GL context on the
  first screencopy capture, taking the compositor down. Root-caused by
  A/B-ing the same build with only the readback removed; capture now renders
  an offscreen pass.
- Output mode was resent every frame at 60Hz, flooding any client bound to
  wl_output with duplicate mode/done events.
- general.default_layout was defaulted and validated but never read, so
  setting it did nothing. srdwm is dynamic-first (Windows/macOS style, with
  drag-to-edge snapping); tiling is one opt-in layout, and that stays true.
- .gitignore's unanchored `srdwm` matched any path component of that name,
  silently excluding the whole crates/srdwm source crate - the binary crate
  the workspace lists as a member, so a fresh clone could not build.

Modularization
lib.rs went from ~1260 lines to 78: state, protocols, input, lock,
screencopy, winit and udev now each own one responsibility. lock is grouped
by feature rather than kind on purpose, since its security invariant spans
state, protocol handling and rendering at once.

Multi-monitor was verified in the QEMU VM with a two-output virtio-gpu: both
heads screendumped at their own resolution showing srdwm's clear colour, and
a window forced to global x=1500 landed on head 1 at head-local x=220 while
head 0 stayed empty. Known limitation, now documented: the nested winit
backend stalls while its window is occluded, because the host stops
scheduling frames and eglSwapBuffers blocks.

1 files changed, 1 insertions, 0 deletions

diff --git a/Cargo.lock b/Cargo.lock
index 5484ebc..cfead32 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -1890,6 +1890,7 @@ dependencies = [
  "srdwm-core",
  "srdwm-platform",
  "thiserror 2.0.18",
+ "wayland-protocols-wlr",
 ]
 
 [[package]]