fix(work): Windows terminal Ctrl+C/Ctrl+V copy-paste (DAN-71)

[danielss-dev]

Summary

Windows/Linux embedded Work terminals now follow VS Code / Windows Terminal clipboard behavior:

• Ctrl+C copies the xterm selection when one exists and does not send SIGINT.
• Ctrl+C with no selection still forwards to the PTY (interrupt).
• Ctrl+V pastes clipboard text through Terminal.paste.
• Ctrl+Shift+C/V, right-click Edit menu Copy/Paste, and macOS ⌘C/⌘V are unchanged.

Implementation

Hook: xterm Terminal.attachCustomKeyEventHandler in TerminalPane (ui/src/views/Work.tsx), immediately after onData.

Decision helper: terminalClipboardAction / consumeTerminalClipboardKey in ui/src/lib/terminalClipboard.ts. Copy uses existing copyToClipboard; paste uses navigator.clipboard.readText then instance.paste.

App.tsx still does not reclaim Ctrl+C/Ctrl+V inside .work-terminal-host on Windows/Linux (only Mod+[1-8]). A comment now points at the TerminalPane handler so those keys stay terminal-owned.

Linear: DAN-71

Proof

• pnpm --filter ./ui exec tsc --noEmit — pass
• pnpm --filter ./ui test — 97 files / 543 tests pass, including 11 new cases in terminalClipboard.test.ts (selection copy, bare Ctrl+C forward, Ctrl+V paste, Shift variants, macOS no-claim, non-Latin KeyC/KeyV)
• This environment is Linux and cannot run a Windows Strand / WebView2 build, so live ConPTY Ctrl+C/Ctrl+V was not exercised here.

Out of scope

Full keybinding redesign, external Open-in-terminal, WSL-only bugs.