fix(cli): preserve Ctrl-J newline in CR/LF terminals

[dso2ng]

Summary

• preserve c-j as a newline key in known local terminals that distinguish Enter (CR) from Ctrl-J/Ctrl+Enter (LF)
• add TERM_PROGRAM-based coverage for WezTerm and WarpTerminal plus Kitty's KITTY_WINDOW_ID
• keep the existing fallback for unrecognized local POSIX/thin PTYs where plain Enter may arrive as LF and still needs to submit

Why

On Linux WezTerm, Ctrl-J reaches prompt_toolkit as bare LF (c-j). Hermes currently binds c-j to submit on local POSIX terminals, so Ctrl-J submits the turn instead of inserting a newline.

The existing #22379 fix already avoids binding c-j to submit in Windows, WSL, SSH, and Windows Terminal environments where LF represents a distinct newline-intent keystroke. This PR extends that same environment-gated approach to known local CR/LF-distinguishing terminal environments instead of enabling blanket POSIX behavior.

Related work

• Builds on the environment-gated approach from fix(cli): make Ctrl+Enter insert newline on WSL/SSH/Windows Terminal #22777 / Ctrl+Enter newline submits prompt over SSH/WSL because c-j is bound as submit #22379.
• Related to fix(cli): preserve LF as newline in Warp terminal (Shift+Enter regression #22908) #23921, but generalizes the terminal detection beyond Warp while keeping the scope limited.
• Avoids the opposite failure mode in CLI: Enter key inserts newline instead of submitting — c-j binding breaks prompt_toolkit safety net #9299 by leaving c-j submit enabled for unrecognized local thin PTYs.
• Not a duplicate of fix(tui): preserve raw LF for Shift+Enter newline #18229: that PR is TUI / hermes-ink raw LF handling, while this PR is classic Python CLI / prompt_toolkit keybinding behavior.

Test plan

• python -m pytest tests/cli/test_ctrl_enter_newline.py -o addopts= -q

[alt-glitch]

Related: #23921 (Warp terminal Shift+Enter regression). This PR generalizes the terminal detection to also cover WezTerm and Kitty via TERM_PROGRAM / KITTY_WINDOW_ID env vars, extending the same _preserve_ctrl_enter_newline() predicate that #22777 introduced.

[dso2ng]

Refresh update: I rebased this branch onto current origin/main and resolved the cli.py / tests/cli/test_ctrl_enter_newline.py conflicts while preserving the newer Ghostty handling and the WezTerm/Kitty/Warp Ctrl-J newline detection.

Updated head: ee4b5480f

Targeted local verification on the updated head:

• git diff --check origin/main...HEAD -> passed
• python -m py_compile cli.py tests/cli/test_ctrl_enter_newline.py -> passed
• python -m pytest tests/cli/test_ctrl_enter_newline.py -o 'addopts=' -q -> 12 passed
• non-ASCII diff guard -> non_ascii_added_lines=0

GitHub Actions is still blocked at the fork workflow approval gate (action_required, zero jobs started). Once a maintainer approves/runs the workflows, I can follow up on any real CI failures.

[teknium1]

Thanks for extending the existing environment-gated classic-CLI behavior. Current main still binds c-j to submit when _preserve_ctrl_enter_newline() is false (cli.py:3189-3190), while its predicate has no WezTerm, Warp, or Kitty marker (cli.py:3149-3171), so the PR targets a live path.

Problems

• cli.py:2486 adds WarpTerminal to the new allowlist, but tests/cli/test_ctrl_enter_newline.py:66-77 only adds WezTerm and Kitty coverage. The Warp branch would be unprotected.

Suggested changes

• Add a TERM_PROGRAM=WarpTerminal regression case; ideally verify the resulting _bind_prompt_submit_keys() binding as well as the predicate result.

Automated hermes-sweeper review.

[teknium1]

WarpTerminal is introduced here but has no matching regression fixture: the added tests cover WezTerm and Kitty only. Please add a WarpTerminal environment case so every allowlisted TERM_PROGRAM value is covered.

[dso2ng]

Thanks — addressed on current head 94b4ef5b9dd1c57dc9eab4cfbff007b0f777f3a9.

• Added a TERM_PROGRAM=WarpTerminal regression case for the newly allowlisted value.
• The regression checks both the predicate and the effective prompt binding: c-m remains submit while c-j stays unbound for the Ctrl+J/Ctrl+Enter newline handler.

Targeted verification:

python -m py_compile cli.py tests/cli/test_ctrl_enter_newline.py
python -m pytest tests/cli/test_ctrl_enter_newline.py tests/cli/test_cli_init.py::TestPromptToolkitTerminalCompatibility::test_lf_enter_binds_to_submit_handler_posix -o 'addopts=' -q
14 passed in 0.34s

git diff --check origin/main...HEAD
non_ascii_added_lines=0

Please re-review when convenient.