TUI: text typed while a submit POST is in flight is silently destroyed

Found by seeded network-chaos property testing with opencode-drive (seeds 1, 7, and 99 of the network-properties probe all reduced to this).

The prompt component clears the composer only after the awaited session.prompt POST resolves (packages/tui/src/component/prompt/index.tsx, submit handler: POST is awaited, then history.append({...store.prompt}), setStore("prompt", emptyPrompt()), input.clear()). Anything typed during that in-flight window:

• is appended to the still-visible previous prompt text,
• has its enter dropped,
• is destroyed by the post-await input.clear(),
• and is recorded in prompt history as a merged entry that was never sent (history.append reads the live store.prompt, not the captured inputText the POST actually used).

Deterministic repro (drive script test/manual/tui-regressions/type-during-submit.ts in opencode-drive): add 800ms latency between TUI and server, submit FIRST probe, type and enter SECOND probe 250ms later. Result: SECOND never reaches the server, is not in the composer, and no error is shown, while prompt-history.jsonl contains "FIRST probeSECOND probe" as one entry:

Real-life shape: type-ahead on a slow connection. The first prompt of a new session has the widest window (session create + model switch + the 50ms navigate hack all happen inside the await), so typing your next message right after enter on a slow link eats it with no feedback.

Steers on a fast connection are fine (probed 0-1800ms offsets into a streaming reply, all admitted); the loss needs the POST itself to still be in flight.

A likely fix is to clear the composer synchronously at submit and restore the captured text on failure (the failure path already restores today), but that is a product call about optimistic clearing, so filing rather than PRing.