bug: Terminal has no way to copy selected text (desktop web & mobile)

Bug

Text selected in the web terminal can never reach the clipboard. There is no working copy path on desktop browsers, and no copy affordance at all on touch devices. Paste works fine (via keyboard), so the terminal is effectively one-way.

Reproduction

1. Run cptr run --host 0.0.0.0, open the UI from another device (or any browser).
2. Open a terminal, run a command, drag-select some output text.
3. Try to copy it:
   • Cmd+C / Ctrl+Shift+C → nothing lands on the clipboard
   • Right-click → no context menu appears
   • On touch devices → long-press selection doesn't work, and there is no copy button

Root cause (from the shipped frontend bundle, v0.9.12)

The terminal's custom input layer registers these handlers:

pointerdown/move/up  → forwarded over the WebSocket
keydown/keyup        → forwarded over the WebSocket
paste                → reads e.clipboardData and forwards the text   // paste works
contextmenu          → e.preventDefault()                            // native menu killed
copy                 → (no listener at all)

So:

1. No copy event handler exists. The selection highlight is purely visual (canvas-rendered, not a DOM selection), so the browser's built-in copy can't help, and nothing moves selectionText into the clipboard.
2. contextmenu is preventDefault'd, which also defeats xterm.js's built-in right-click fallback (focus hidden textarea + select text so the native menu's "Copy" works).
3. The only selection-driven path in the bundled xterm fork is onLinuxMouseSelection, which just populates the hidden textarea (X11 PRIMARY semantics) — no clipboard write, and Linux-only anyway.

Side note: all other copy buttons in the UI use navigator.clipboard.writeText() with no fallback. When the UI is served over plain HTTP on a LAN IP (http://192.168.x.x:8000), that's not a secure context, so navigator.clipboard is undefined and those buttons silently fail too. A warning toast would help discoverability.

Suggestions

• Add a copy event listener on the terminal's input element: e.clipboardData.setData('text/plain', term.getSelection()) works even in insecure contexts, no permissions needed — this fixes keyboard copy on desktop for free.
• Don't blanket-preventDefault contextmenu on desktop; or replace it with a small custom menu (Copy / Paste) like most web IDEs do.
• On touch: show a floating "Copy" button when the selection is non-empty.
• Add an execCommand('copy') fallback or a visible warning when navigator.clipboard is unavailable.

Environment

• cptr 0.9.12 (installed via pipx), host: macOS (Apple Silicon)
• Clients tested: desktop Chrome and mobile browser over LAN HTTP

Disclosure: this issue was investigated, root-caused, and drafted by Kimi K3 while helping me debug the terminal copy behavior in a chat session, and is submitted on my behalf at my request. The analysis above is based on reading the shipped v0.9.12 frontend bundle; I verified the described behavior reproduces on my setup.

Start by locating the terminal input element and the frontend handlers described in the shipped v0.9.12 bundle, especially the copy and contextmenu paths. Reproduce selection on desktop and touch devices, then verify that selected text reaches the clipboard, touch users have a copy affordance, and insecure-context failures are visible rather than silent.