fix: bracket multi-line terminal pastes so pasted code isn't treated as Enter

[SmolSmolStar]

Summary

Pasting multi-line code into a terminal (e.g. a SQL block or a snippet from chat) misbehaves: the paste is sent to the PTY as a raw string, so every newline is read as an Enter keypress. The result is code that submits line-by-line or early instead of landing as one clean block. This affects both the worktree terminals and the Commander terminal.

Root cause

The paste handlers send the clipboard text straight through (sendTerminalInput / sendInput) with no bracketed-paste wrapping. Bracketed paste (ESC[200~ … ESC[201~) is the mechanism that tells a program "this is pasted text — treat the newlines as literal input, don't act on them." Without it, multi-line pastes are indistinguishable from a burst of typed Enters.

Change

• client/terminal.js (worktree terminals): the three raw-send sites now route through a new pasteTextToTerminal() helper that calls xterm's own terminal.paste(). That normalizes newlines and, only when the running program has bracketed-paste mode enabled (it sent ESC[?2004h), wraps the text in ESC[200~ … ESC[201~. It flows through terminal.onData (which already forwards to sendTerminalInput and marks the session active), and updateInputBuffer ignores ESC-prefixed data so autosuggestions aren't polluted. Falls back to a raw send if the xterm instance is unavailable. Image paste is untouched.
• client/commander-panel.js (Commander terminal): its paste handler intentionally bypasses xterm.onData (to keep pastes out of slash-command capture), so it brackets inline via a small bracketPastedText() helper that reads terminal.modes.bracketedPasteMode.
• No regression for plain programs: anything that doesn't enable bracketed-paste mode receives the text unwrapped, exactly as before.

Test plan

• Extends tests/e2e/commander-paste.spec.js with a multi-line case: with bracketed-paste mode enabled, the POST /api/commander/input body must be ESC[200~line one\rline two ESC[201~. The existing single-line / mode-off case still asserts a raw body (guards against regressions).
• The underlying mechanism (xterm terminal.paste() bracketing + terminal.modes.bracketedPasteMode reflecting ESC[?2004h) was verified in a headless browser against xterm 5.3.0.
• Note: I could not execute the e2e suite locally on Windows (the repo's e2e webServer command uses POSIX VAR=value env-prefix syntax that cmd.exe rejects, and the run-e2e-safe.js runner spawns npx which doesn't resolve under Git Bash). The tests are discovered by playwright --list and will run in CI on Linux.

🤖 Generated with Claude Code

[web3dev1337]

Reviewed as part of an open-PR sweep — the mechanism was verified against the real xterm 5.3.0 source (modes.bracketedPasteMode is a stable API; paste() normalizes and brackets exactly as this PR assumes) and the orchestrator's server-side two-write submit path is confirmed untouched. One real regression found and fixed: unbracketed multi-line pastes now flowed through onData into the autosuggestion input-buffer tracker and were stored whole as the current line, later polluting command history. Pushed a fix that flags paste-originated bursts (paste() fires onData synchronously) so tracking skips them, plus ESC[201~ terminator-injection hardening for the Commander's hand-rolled wrapper and a comment on the deliberate fail-open fallback. Verdict after fix: good to merge.