feat(x11): opt-in capture-time X11 takeover so XWayland can paste images

[davidboulay]

No version bump. This wants testing on a real copy before it ships.

The gap

An image copied on Wayland can't be pasted into an XWayland app — Claude Desktop runs --ozone-platform=x11. Xwayland exports text selections to X11 but never image ones, and a wlr-data-control clip (what CosmicShot's wl-copy writes) never reaches X11 at all. So those apps aren't reading it slowly; they have nothing to read.

Recovering the same clip from the Clippy panel does paste — because that path makes our helper the X11 selection owner and it serves the bytes itself.

Why this was previously considered dead

_MIRROR_ON_CAPTURE existed to do exactly that at capture time. Shipped in 1.4.21, reverted in 1.4.22: cosmic-comp copies our X11 offer into the Wayland selection, Xwayland re-takes X11 ~35s later to proxy it, Xwayland can't serve image data, and both channels end up advertising an offer nothing backs. The comment concluded owning X11 was itself the problem.

What changed: that conclusion doesn't hold

Re-measured with the GTK consumer probe (not xclip, which lies about this):

t+8s   image/png: 22211  0.0s  decodes: true
t+46s  image/png: 22211  0.0s  decodes: true
t+85s  image/png: 22211  0.0s  decodes: true

The recover path publishes through the same helper and does not decay. So owning X11 isn't what breaks it. The difference is that a recover displaces the previous owner, while a capture-time grab races an app still holding the Wayland selection — two authorities for one selection, the same failure class the CosmicShot side deliberately avoided.

That's worth retesting rather than presuming dead.

The change

_MIRROR_ON_CAPTURE becomes the x11_image_takeover setting — default off, images only, still behind the existing _mirror_allowed() rate cap, still short-circuiting on our own echo by content hash.

// ~/.config/clippy/settings.json
"x11_image_takeover": true

Restart the daemon, copy an image in CosmicShot, paste into Claude Desktop.

Failure mode if the hypothesis is wrong: both channels go empty a few seconds after any image copy — clipboard dead system-wide, not just in XWayland apps. Turn it back off. That risk is why it's opt-in rather than a default.

Tests

scripts/x11_takeover_gate_test.py (new, in CI) pins what must not drift: ships off; off publishes nothing and still releases; on publishes and does not release; our own echo short-circuits before either path; the rate cap bounds republishes.

Mutation-checked — flipping the default to True, and ignoring the setting, each fail it:

mutation A: x11_image_takeover must default to False — True
mutation B: off must not publish — ['image/png']

Full suite green locally (8 scripts).