fix(cli): preserve classic multiline on macOS

[LeonSGP43]

Summary

• keep c-j reserved for newline in the classic CLI on local macOS, so Shift+Enter paths that collapse to LF stop submitting the prompt
• preserve the existing LF-submit behavior for thin PTYs via HERMES_CLI_SUBMIT_ON_LF=1
• add regression coverage for macOS default behavior and the explicit LF-submit opt-in

Closes #22908.

Why this stays narrow

• only touches classic CLI keybinding decisions in cli.py
• keeps the existing Windows/WSL/SSH/WT Ctrl+Enter newline behavior intact
• does not change TUI multiline shortcuts; #22909 remains separate

Verification

• git diff --check
• ./.venv/bin/python -m pytest tests/cli/test_cli_init.py tests/cli/test_ctrl_enter_newline.py tests/cli/test_cli_shift_enter_newline.py
• uv sync --frozen --extra all
• uv run --frozen ruff check .
• env -i PATH="$PATH" HOME="$HOME" TERM="${TERM:-xterm-256color}" TZ=UTC LANG=C.UTF-8 LC_ALL=C.UTF-8 PYTHONHASHSEED=0 ./.venv/bin/python -m pytest -o addopts= --collect-only --ignore=tests/integration --ignore=tests/e2e -m 'not integration'
• repo ruff/ty lint-diff against b67ea7ff474831743b14edefb6c9113cb12216e7 (touched files: 0 new ty diagnostics)

Left out

• no TUI fallback shortcut changes
• no docs changes beyond the code comments/tests needed to pin behavior

[hanzckernel]

Verified this covers the Apple Terminal regression I hit after #22777:

• local environment reports TERM_PROGRAM=Apple_Terminal
• Ctrl+J/bare LF currently submits in classic CLI on v0.13.0
• Apple Terminal does not reliably emit the Esc, Enter sequence for physical Option+Enter, so the practical fallback is only manual Esc then Enter or editor mode

I checked out this PR and ran the focused CLI coverage locally:

scripts/run_tests.sh tests/cli/test_cli_init.py tests/cli/test_ctrl_enter_newline.py tests/cli/test_cli_shift_enter_newline.py -q
51 passed in 3.83s

The HERMES_CLI_SUBMIT_ON_LF=1 escape hatch looks like the right way to preserve the thin-PTY behavior without making normal local macOS multiline input worse.

[teknium1]

Thanks for the focused regression analysis and tests. The macOS c-j issue is real on current main, but this PR cannot be accepted in its current configuration form.

• The PR adds HERMES_CLI_SUBMIT_ON_LF as a user-facing, non-secret behavioral toggle (cli.py in commit c193fdffa24597132d0379b2a1eb61f118168eaf).
• Maintainer policy is that new non-secret HERMES_* environment variables are not configuration surfaces; behavioral settings belong in config.yaml (AGENTS.md:102-107).
• The current classic-CLI behavior remains relevant: local macOS falls through to the c-j submit binding at cli.py:3187, while the newline handler is conditional on _preserve_ctrl_enter_newline() at cli.py:13575.
• A follow-up can re-scope the compatibility choice to an appropriate config.yaml setting (with config plumbing and tests), while preserving current Ghostty detection at cli.py:3153-3158 from cf8862cfa.

This is an automated hermes-sweeper review.

---

Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.