fix: preserve Ctrl+J newlines in Ghostty

[seppegadeyne]

Summary

• Preserve Ctrl+J/Ctrl+Enter newline behavior in Ghostty sessions, including tmux-inherited Ghostty environments.
• Keep plain Enter mapped to submit for local POSIX terminals that still need LF-as-submit compatibility.
• Add CLI and TUI regression coverage for the Ghostty Ctrl+J newline path.

Verification

• venv/bin/python -m pytest tests/cli/test_ctrl_enter_newline.py tests/cli/test_cli_init.py -q → 52 passed
• npm test -- src/__tests__/textInputPassThrough.test.ts in ui-tui/ → 6 passed

Notes

• A system-Python pytest attempt failed before using the project venv because optional test dependencies such as prompt_toolkit/python-dotenv and pytest-timeout were not available in system Python. The venv run above is the relevant verification.

[alt-glitch]

Fixes #9299. Competing open PRs for Ctrl+J/newline: #25111, #22911 (most comprehensive — also handles Warp), #26086, #27688.

[seppegadeyne]

Thanks for the pointer — I missed the existing issue/competing PRs before opening this. Sorry for the duplicate review noise.

I agree this overlaps with #9299 and the open Ctrl+J/newline PRs (#25111, #22911, #26086, #27688). The only intended extra scope in this PR is:

• Ghostty detection that survives tmux masking TERM / TERM_PROGRAM via the stable GHOSTTY_* env markers
• TUI handling/tests for the same bare-LF / Ctrl+J behavior in Ghostty
• focused verification for the Ghostty-on-Linux case I hit locally

I don’t want to fragment the review further. Maintainers, what would you prefer?

1. I close this PR and move the Ghostty/TUI testcase/patch as a comment or suggested diff onto the canonical PR, likely fix(cli): preserve classic multiline on macOS #22911.
2. I keep this PR open as a Ghostty/TUI-specific variant and update the body to Refs #9299.
3. I rework this on top of whichever PR you choose as canonical.

Unless there’s a preference to keep this separate, I’m happy to close this and transfer the unique Ghostty/TUI bits to the canonical thread.