Fix Wayland FD leak and clipboard sync feedback loop

[halfcrazy]

Summary

• Add WlrBackend with a persistent Wayland data-control connection, mirroring the existing X11Backend pattern, so polling no longer opens a new wl-clipboard-rs session on every get()/set() and exhausts file descriptors (EMFILE after ~5 minutes under GNOME Wayland).
• Upgrade wl-clipboard-rs to 0.9.3 and wayland-client to 0.31.14 (adds ext-data-control support on GNOME).
• Rewrite keep_synced to track per-clipboard last-known content and add a short post-sync settle period, preventing the X11/Wayland write-lag feedback loop that spammed clipboard updated from display :1 logs.

Fixes #50

Root cause

WlrClipboard called wl_clipboard_rs::paste::get_contents() / copy::Options::copy() on every poll (~5 Hz per clipboard). Each call runs initialize() and opens a new Wayland socket, leaking FDs until ulimit -n is hit.

Separately, after syncing a change, comparing all clipboards against clipboards[0] caused repeated false positives when Wayland and X11 reads diverged briefly after a write.

Test plan

• Run under GNOME Wayland with WlrClipboard { wayland-1 } + X11Clipboard { :1 }
• Confirm FD count stays stable (~28) during polling instead of growing ~3–4/sec
• Copy text on Wayland side; verify it appears on X11 side
• Confirm only one log line per user copy (no :1 spam)
• Process survives beyond 10 minutes without EMFILE panic

Made with Cursor