tui: playbook paste prefers a stale internal clipboard over the system clipboard #1095

Paste in the Playbook reads the internal buffer first and only falls back to the system clipboard:

let text = self
    .playbook_clipboard
    .clone()
    .or_else(|| read_from_clipboard().ok());

(crates/cli/src/app/editor.rs ~line 2429 @ ad47152)

playbook_clipboard is set by every in-Playbook copy/cut (copy_playbook_text, ~line 2379) and is never cleared. So the first copy inside the Playbook pins paste to that text for the rest of the session: anything the user copies afterwards in a browser, another pane, or another app is unreachable via C-y/C-v in the Playbook.

This is the common flow it breaks: copy a URL or a snippet from a browser → focus the Playbook → paste → get a line you copied out of the Playbook ten minutes ago.

Repro

1. In the Playbook, select some text and copy it (M-w).
2. Copy different text from any other application.
3. Put the caret in the Playbook and press C-y (or C-v).

Observed: the text from step 1 is inserted. Expected: the text from step 2.

Expected

Prefer the system clipboard, and use the internal buffer only as a fallback for environments where the clipboard is unavailable (headless, no OSC 52, no pbcopy). Alternatively track which of the two was written most recently.

An emacs-style kill ring is a reasonable richer answer, but the minimum fix is that a fresh system-clipboard copy always wins over a stale internal one.

Acceptance criteria

• After copying outside Construct, pasting in the Playbook inserts the external text.
• Paste still works when the system clipboard is unavailable (internal fallback preserved).
• Test covering "internal copy, then external copy, then paste".

Found during a hands-on UX audit of the Playbook in the TUI and web UI.