feat: multi-line input+edit

[SusieGlitter]

now in interactive mode, we can use multi-line input and edit

ctrl+j for newline and arrow keys for movement, abling edit in the middle

[SusieGlitter]

most of code agents or even chat apps use ctrl+enter or shift+enter for a new line

however the framework TextArea that OpenCook uses to construct cli interface takes the key enter as a special input, ctrl+enter or shift+enter will be distinguished with enter.

so change the key of newline to enter+xxx is imposible, pitifully

[SusieGlitter]

commit: 92e22e3

by changing config to

Input, TextArea {
    height: auto;
    min-height: 1;
    max-height: 8;
    border: ascii #1a2438;
    background: #0a1020;
    color: #e2e8f0;
    padding: 0 1;
}

now with zero or one line input, the input area will be just one line high and grow with extra line inputted (always three before this commit)

@Beliefuture

[code4DB]

@SusieGlitter

I found two reproducible issues:

1. Multiline Up/Down is overridden by input history.

Repro:

• Start the TUI on this PR branch.
• Submit any prompt once, so input history is non-empty.
• In the input box, type line 1.
• Press Ctrl+J.
• Type line 2.
• Press Up.

Expected:
The cursor should move within the multiline textarea.

Actual:
The current multiline draft is replaced by the previous history entry.

Cause:
OpenCookApp.on_key still handles Up/Down for history even when the input contains multiple lines.

2. Input._on_key calls async TextArea._on_key without await.

Repro:

• Use a current Textual version, e.g. textual==8.2.8.
• Type normal characters in the custom Input.

Actual:
Runtime warning appears:

RuntimeWarning: coroutine 'TextArea._on_key' was never awaited

Fix suggestion:
Make Input._on_key async and await super()._on_key(event), or remove the manual super() call and let Textual continue dispatching normally.