Lite Terminal: don't repaint a pasted block taller than the viewport

[globalerp-mhess]

Follow-up to #1866 and #1862, which fixed the coloring itself. One case still misdraws: a paste
taller than the terminal window.

Coloring a submitted paste repaints the input in place — save the cursor, move up the number of rows
computed for the input, erase, redraw, restore. That upward move is unfulfillable once the input is
taller than the window, because \x1b[nA stops at the top row. The redraw then starts as many rows
too low as the input exceeds the viewport, which leaves the top of the original block on screen and
puts the command's output inside the second copy.

Measured with a 31-line paste of set a01=1 … set a30=30: in a 49-row window the handler moves up
30 rows and the result is correct; in a 20-row window it computes the same 30 and lands 11 rows off —
exactly the overflow. Nothing in the class can notice, since setDimensions receives
dimensions.rows but only columns is kept. On the commit before #1866 the same paste renders
correctly, so it is the repaint and not the raw echo: a downward correction clamping at the bottom
row happens to land where it wants to be, an upward one does not.

The change: input that arrives with its own carriage return is submitted straight away, so its echo
is never corrected by a later keystroke. Hold that echo back and let the color handler write the
colored text in its place. A plain write at the position the raw text would have occupied has no
arithmetic in it, so the height of the block stops mattering. The 100 ms window and the
_state != "prompt" guard from #1866 are unchanged; if no coloring arrives in time the raw text is
written instead — uncolored as before, but never invisible. Typed input keeps the existing repaint,
which is correct for it, since every keystroke colors a block already on screen.

Verified against IRIS 2026.3.0AI: the 31-line paste is colored and correct in a 20-row window, where
it was misdrawn before, and unchanged in a tall window; typed multi-line input with Enter behaves as
before.

Edit for clarification:

With #1866 in place — 31-line paste into a 20-row window. The block is drawn twice and the
command's output lands inside the second copy:

Same paste, same window, with this change:

[isc-bsaviano]

Thanks for the PR @globalerp-mhess!

@isc-klu This seems fine to me but I want your review since it's related to your change.

[isc-klu]

@isc-bsaviano I am not sure if we still need to check this._state but we can leave it as a future task for ourselves.