TUI: multi-line paste auto-submits at the first line break; right-click paste does nothing (Windows Terminal / conhost)

Summary

│
│ Two paste-related bugs on Windows Terminal / conhost, both caused by the TUI's
│ handling of pasted text when the terminal does not deliver a bracketed paste:
│
│ 1. Multi-line paste auto-submits at the first line break.
│ Pasting text containing newlines (e.g. terminal output) submits the draft at
│ the first line break instead of inserting the pasted lines as content.
│
│ 2. Right-click paste does nothing when mouse_capture is enabled.
│ With mouse capture on (the default on Windows Terminal / conhost), the
│ terminal's native right-click paste never fires, and the TUI has no
│ right-click handler, so right-click silently does nothing.
│

Environment

│
│ - OS: Windows
│ - Terminal: Windows Terminal (launched from PowerShell)
│ - jcode: 0.75.3 (TUI)
│ - Config: [display] mouse_capture = true
│

Repro (multi-line paste)

│
│ 1. Copy two or more lines of text, e.g.:
│
│ │ GROMACS reminds you: "You Dirty Switch, You're On Again" (The Breeders) │ (base) [xxxx@xxx xxxx]$ │
│
│ 2. Paste it into the composer with Ctrl+V.
│ 3. The draft is submitted at the first line break; only the first line is sent.
│
│ Single-line pastes (no newline) insert fine, which narrows it to the newline
│ handling.
│

Root cause

│
│ When the terminal does not wrap pasted text in bracketed-paste markers, a
│ multi-line paste arrives as a burst of key events, and each newline inside the
│ paste is delivered as an ordinary Enter key event. The Enter handler then
│ submits the draft.
│
│ The existing fix (#544) only covers the bracketed-paste case (a single stray
│ Enter delivered after a bracketed paste); it does not cover a raw key-stream
│ paste where every newline is a separate Enter.
│

Fix (in progress)

│
│ A paste-burst detector in paste_guard.rs:
│
│ - Each character arrival is timestamped.
│ - When more than 8 characters arrive within 100 ms (far faster than a human can
│ type), a short "active" window is armed during which an Enter is inserted
│ as a newline instead of submitting.
│ - Normal typing never meets the threshold, so a regular Enter still submits.
│
│ Plus, a right-click paste handler in navigation.rs: a right-click press
│ reads the clipboard and inserts it at the composer, exactly like Ctrl+V.
│
│ A reference implementation is on my fork:
│ https://github.com/RushengL/jcode/tree/fix/multiline-paste
│ (2 commits, based on current master.)
│

Tests

│
│ - New regression test: raw_key_stream_multi_line_paste_inserts_newlines_not_submits.
│ - Existing bare_enter_immediately_after_paste_does_not_submit (#544) still passes.
└─

Read paste_guard.rs and navigation.rs first, then locate the raw_key_stream_multi_line_paste_inserts_newlines_not_submits regression test and the existing bare_enter_immediately_after_paste_does_not_submit coverage. Verify both Windows Terminal/conhost cases: multiline paste keeps its newlines without submitting, and right-click paste inserts clipboard content when mouse capture is enabled.