feat(chat): non-blocking input with send queue

[smorchj]

Summary

Users can now type and send a new message while the previous response is still streaming. Messages sent during a stream are pushed to a local queue and rendered as dimmed user bubbles with a small amber `queued` pill (same palette as `.stream-badge` and `.interrupted-banner`). When the active stream finishes, the queue drains automatically in order. Stop aborts only the current stream — queued messages persist.

Before this PR the textarea was `disabled={$chatStore.isLoading}`, blocking any typing during a response. That broke the feel of a real conversation compared to Claude Code itself, which accepts follow-up messages mid-stream.

Important caveat (read before merging)

This PR is scoped strictly to the concurrent-input feel — it does NOT solve the bigger self-hosting problem, which is that Vite HMR / dev-server restarts sever in-flight streams when Klonode edits its own files. That architectural fix requires a detached Claude worker (separate long-lived process, persistent log, reconnect-on-reload) and is tracked separately as a follow-up issue.

Use this PR as a daily-driver polish improvement. Do not assume it makes Klonode's self-editing bullet-proof.

How this PR was written

Written by Claude running inside the Klonode Workstation chat panel, solving the task through its own UI. The user pasted the task description into the chat textarea and clicked send. Claude read `ChatPanel.svelte` in chunks (it's ~1150 lines), added the queue plumbing, updated the store, and committed on this branch. Third time Klonode has written a PR on itself through its own UI (see PR #67 PHP, #69 Go).

During the dogfood run the stream appeared "stalled" at 11 Read tool calls — Claude was actually in a long reasoning phase after reading the large file, not stuck. The progress indicator in ChatPanel could use a separate "thinking" state distinct from "streaming tool calls" — also a follow-up.

Test plan

• `pnpm --filter @klonode/core test` — 83/83 passing (unchanged — this PR is UI-only)
• Manual:
  • Send a message, wait for streaming badge, type a second message into the textarea → textarea is NOT disabled
  • Click send → a new user bubble appears with the amber `queued` pill
  • When the current stream completes, the queued message fires automatically
  • Click Stop during the first stream → only the current aborts, the queue stays

Closes

Addresses the "chat feels unresponsive" UX concern raised while dogfooding. The deeper self-hosting architecture issue is tracked separately.