fix(terminal): copy selected text to clipboard automatically

[Its-My-Work]

Summary

Right-click on a terminal pane never offered "Copy" — xterm.js clears the text selection on the right mousedown before the browser's context menu opens, and Ctrl+C can't be repurposed for copying since it's already sent through as SIGINT to whatever's running in the pane. In practice there was no way to copy terminal output at all short of it being echoed elsewhere.

xterm v4's copyOnSelect option was removed upstream; the documented replacement is wiring onSelectionChange() yourself. This copies the selection to the clipboard (via the existing copyText() helper, which already falls back to execCommand for non-secure-context/tunnel use) the moment a selection is made, matching how most terminal apps behave.

Test plan

• Open a terminal pane, click-drag to select some output, confirm it lands on the system clipboard without pressing anything else
• Confirm Ctrl+C still sends SIGINT as before (unrelated to this change)

🤖 Generated with Claude Code

https://claude.ai/code/session_011E2bJQ2sL9LgEWosjvydTR

[Lexus2016]

Thanks — right diagnosis, and copyText() is the right helper (it already has the execCommand fallback for http/tunnel use).

One change, pushed to your fix/terminal-copy branch as a follow-up commit (maintainer edit): the copy now happens in the existing mouseup handler instead of term.onSelectionChange. Checked against the vendored xterm.js: _fireOnSelectionChange is called from the selection service's _refresh, i.e. on every animation frame while the mouse is still dragging. That was a clipboard write per frame — and over plain http copyText() falls back to a focused off-screen <textarea>, which stole focus from the pane mid-drag. mouseup already knows whether a selection was dragged out, so the copy runs there, once, when the drag ends. test/composer-terminal.test.js pins the new shape and asserts onSelectionChange is not used.

npm test → 80 files, exit 0.