[VSCode] Prompt sent during an untracked live turn vanishes until the turn ends

Bug description

Hitting enter on a prompt sometimes does nothing visible: the text flashes and later reappears in the composer. It never enqueues.

Root cause

loadSession in the webview chat store resets isStreaming: false unconditionally, even when the session has a live, in-flight turn (e.g. after a window reload or reattach). With the store believing the session is idle, sendMessage takes the send path instead of enqueueing; the extension runtime correctly rejects it (turn.agent_busy, non-terminal warning), and the text is left parked in pendingInput with isStreaming: true and no TurnBegin — invisible limbo. Only when the other turn's terminal event eventually arrives does the composer restore the text.

The webview also cannot tell this case apart from a normal turn end: streamChat's bridge result ({done: false} on a busy bounce) is currently ignored — doSend only handles rejections.

Reproduction

1. Start a long-running turn in a chat.
2. Reload the VSCode window (or otherwise reattach the webview mid-turn).
3. Type a prompt and hit enter.
4. The prompt flashes and vanishes; it is neither sent nor queued. It reappears in the composer only when the running turn finishes.

Suggested fix

Mark the runtime's busy rejection (PromptResult.reason = "busy") and pass it through the bridge (streamChat → { done, bounced }), so the webview can move a bounced message into the send queue (flushed when the live turn's terminal event arrives) instead of parking it. Sends that fail before their TurnBegin for any other reason should roll the text back into the composer immediately.

Start at loadSession in the webview chat store, then trace sendMessage, streamChat, and doSend across the bridge, including PromptResult.reason and TurnBegin handling. Reproduce a reload during a live turn and verify that busy bounces enter the send queue, flush after the terminal event, and other pre-TurnBegin failures restore the text to the composer.