fix(desktop): copy to clipboard on native Wayland sessions

[ricardoraposo]

Summary

Copy-to-clipboard actions silently failed on native Wayland Linux sessions. arboard was declared with default features, so on Linux it only talked to the X11 clipboard (through XWayland). On a native Wayland session those writes don't reliably propagate to Wayland apps, so nothing landed in the clipboard.

Fix

Enable arboard's wayland-data-control feature, which pulls in wl-clipboard-rs and uses the native Wayland wlr-data-control protocol (with automatic X11 fallback for XWayland/X11 sessions).

arboard = { version = "3", features = ["wayland-data-control"] }

The app already retains clipboard ownership for the process lifetime via ClipboardState (see desktop/src-tauri/src/commands/clipboard.rs), which satisfies Wayland's requirement that the source client stay alive to serve paste requests — so no additional lifecycle changes were needed.

Changes

• desktop/src-tauri/Cargo.toml — enable the wayland-data-control feature on arboard.
• desktop/src-tauri/Cargo.lock — adds wl-clipboard-rs and its wayland dependencies (12 new entries, no existing crates removed or version-bumped).

Testing

Built and ran on Fedora 43 (Sway, XDG_SESSION_TYPE=wayland):

cargo build --release -p buzz-acp -p buzz-agent -p buzz-dev-mcp -p git-credential-nostr -p buzz-cli
./scripts/bundle-sidecars.sh
cd desktop && pnpm tauri build --bundles deb

Launched the built binary, clicked a copy button, and confirmed the text was retrievable via wl-paste and pasteable into other Wayland apps. Before the change, the same actions produced nothing in the clipboard.

[ricardoraposo]

Closing this out — #2904 landed the same fix independently (enabling arboard's wayland-data-control feature), so this is now redundant. Same root cause and same solution; glad it's fixed on main. 👍