Orca's terminal already encodes Shift+Enter as the kitty CSI-u sequence
`\x1b[13;2u`, but without `vtExtensions.kittyKeyboard` xterm.js never
answers the `CSI ? u` probe. CLIs that gate enhanced input on that
handshake (Claude Code, Codex, etc.) therefore drop the extended bytes
and treat Shift+Enter as a plain Enter — most visibly when running
inside tmux, which strips extended-key encodings by default.
- Enable `vtExtensions.kittyKeyboard` in the default terminal options
(matches VS Code's xtermTerminal).
- Lock in the flag with a regression test in pane-lifecycle.test.ts.
- Add docs/terminal-extended-keys.md explaining the Orca side and the
tmux-side `set -s extended-keys on` + `terminal-features xterm*:extkeys`
users need for nested Shift+Enter to reach a CLI.
Verified end-to-end in Electron: `cat -v` + Shift+Enter now prints
`^[[13;2u`, and `printf '\e[?u'` elicits the expected `CSI ? 0 u` reply
from xterm.js.
Co-authored-by: Orca <help@stably.ai>
