fix(tui): harden paste-burst state transitions (#9124)

User-facing symptom: On terminals that deliver pastes as rapid
KeyCode::Char/Enter streams (notably Windows), paste-burst transient
state
can leak into the next input. Users can see Enter insert a newline when
they meant to submit, or see characters appear late / handled through
the
wrong path.

System problem: PasteBurst is time-based. Clearing only the
classification window (e.g. via clear_window_after_non_char()) can erase
last_plain_char_time without emitting buffered text. If a buffer is
still
non-empty after that, flush_if_due() no longer has a timeout clock to
flush against, so the buffer can get "stuck" until another plain char
arrives.

This was surfaced while adding deterministic regression tests for
paste-burst behavior.

Fix: when disabling burst detection, defuse any in-flight burst state:
flush held/buffered text through handle_paste() (so it follows normal
paste integration), then clear timing and Enter suppression.

Document the rationale inline and update docs/tui-chat-composer.md so
"disable_paste_burst" matches the actual behavior.

docs/tui-chat-composer.md

@@ -92,9 +92,9 @@ When enabled:
 - The burst detector is bypassed for new input (no flicker suppression hold and no burst buffering
   decisions for incoming characters).
 - The key stream is treated as normal typing (including normal slash command behavior).
-- Enabling the flag clears the burst classification window. In the current implementation it does
-  **not** flush or clear an already-buffered burst, so callers should avoid toggling this flag
-  mid-burst (or should flush first).
+- Enabling the flag flushes any held/buffered burst text through the normal paste path
+  (`ChatComposer::handle_paste`) and then clears the burst timing and Enter-suppression windows so
+  transient burst state cannot leak into subsequent input.
 
 ### Enter handling