Copy and cut over SSH reach my laptop's clipboard #443

Context

Copy and cut go through the platform clipboard (pbcopy, xclip, the Win32 API) and check it by reading it back. Over SSH that's the remote machine's clipboard, or none, so copying fails. This task also sends the text through the terminal (OSC 52), so over SSH it lands on the clipboard of the machine you're sitting at. First slice of #40.

Acceptance criteria

• Over SSH in iTerm2, WezTerm or kitty, selecting text in the editor and pressing Ctrl+C puts it on the laptop's clipboard: pasting into another app there gives the same text. The same for Ctrl+X, which also removes the text.
• Copying in the Find field over SSH does the same.
• Where the remote has no clipboard, the status bar says the text was copied through the terminal, e.g. Copied 3 lines • 142 characters through the terminal, not Copy failed.
• Locally, copy and cut behave as today, and the status bar reads as today.
• With several carets, what lands on the laptop's clipboard is what Ctrl+V in TuiCode would paste.
• Settings → Terminal in iTerm2 mentions ticking Applications in terminal may access clipboard, so iTerm2 doesn't block or prompt.
• Inside tmux, the Settings → Terminal panel notes set -g set-clipboard on is needed for copy over SSH.

Tests

• The OSC 52 sequence written for a copy: base64 of the text, multi-line and non-ASCII text included.
• Outcome and status wording for each case: platform clipboard worked; platform clipboard failed but the terminal sequence was sent; both unavailable.
• Multi-caret copy sends the same text the platform clipboard receives.
• Very large copies: either sent whole or the status bar says the copy was too large to send through the terminal (pick a cap and test it).

Out of scope

• Reading the clipboard with OSC 52 (paste is Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40's paste task).
• Configuring tmux for the user.
• Detecting SSH: the sequence is sent always.