Ctrl+J submits instead of inserting newline after bare-LF Enter change

## What happened?

`Ctrl+J`, the default `tui.input.newLine` binding, submits the prompt instead of inserting a newline when the terminal sends Ctrl+J as bare LF (`\n`). This makes the documented fallback unusable on affected terminals.

This reproduces in the core `Editor` without extensions: with text `first`, `handleInput("\n")` clears the editor and calls submit with `first`.

PR #156 moved `tui.input.submit` before `tui.input.newLine` so bare-LF Enter submits. In legacy key parsing, the same LF matches both Enter and Ctrl+J, so the submit branch wins. PR #161 says explicit Ctrl+J is preserved, but it is not in this case.

This matters because users on terminals without distinguishable Shift+Enter rely on Ctrl+J for multiline prompts.

## Steps to reproduce

1. Run Senpi in a terminal where Enter sends CR and Ctrl+J sends LF.
2. Type `first`.
3. Press Ctrl+J.

Observed: `first` is submitted.

## Expected behavior

Ctrl+J should insert a newline while Enter still submits. Since some terminals send LF for Enter, this likely needs an explicit ambiguity policy rather than simply reverting #156.

## Version

Senpi 2026.7.31-2; reproduced on WSL2 in Windows Terminal (`TERM=xterm-256color`).

Start at the core Editor's handleInput path and the legacy key-parsing logic for tui.input.newLine and tui.input.submit; compare the behavior described in PRs #156 and #161. Reproduce with handleInput("\n") using text "first", then verify Ctrl+J inserts a newline while CR Enter still submits.

Written by the indexing model from the issue text.