fix(clipboard): fall back wl-copy -> xclip -> xsel on Linux

[jugrajsingh]

Summary

Wayland sessions without XWayland/xclip installed silently failed to copy on both the TUI status-line copy action and the CLI session-share clipboard helper, since both only ever shelled out to xclip on Linux.

Both paths now try wl-copy, then xclip, then xsel, in order (Wayland-native tool first), keeping the first candidate that works. macOS (pbcopy) and Windows (clip.exe) behavior is unchanged. The candidate list is shared via a new clipboard_candidates() helper in src/utils.rs, used by both src/tui/app.rs and src/session.rs, so the fallback order can't drift between the two call sites.

Behavior difference between the two call sites

• CLI (src/session.rs): falls through to the next candidate on spawn failure, non-zero exit, and stdin write/wait errors, since a CLI share command can safely retry silently until one clipboard tool actually works.
• TUI (src/tui/app.rs): falls through only on spawn failure. A spawned-but-failing process surfaces through the status line, and a broader silent retry there would risk misleading UX (user sees "copied" when the paste buffer is actually stale).

No new dependencies — this is pure fallback ordering over binaries that may or may not already be on $PATH.

Verification

• cargo build, cargo fmt -- --check, cargo test --workspace — green.
• 4 new tests covering the candidate list ordering and per-site fall-through semantics (spawn failure vs. exit/write failure).
• Manual: verified copy still works via xclip on an X11 session (regression check) and via wl-copy on a Wayland session without xclip installed.

Test plan

• Wayland session, no xclip → copy succeeds via wl-copy
• X11 session (existing behavior) → copy still succeeds via xclip
• CLI: wl-copy spawns but write fails → falls through to xclip
• TUI: wl-copy spawn fails → falls through to xclip; a spawned-but-failing process does not retry