chore: complete tui-input-queue ticket

TODO.md

@@ -15,7 +15,6 @@
 - TUI 拡充
   - TUI から任意タイミングで Compact を発火する system command → [tickets/tui-system-command-compact.md](tickets/tui-system-command-compact.md)
   - user manifest env override 時の spawn scope overlay 前提ズレ → [tickets/tui-user-manifest-env-overlay.md](tickets/tui-user-manifest-env-overlay.md)
-  - Run 中の入力キューイング → [tickets/tui-input-queue.md](tickets/tui-input-queue.md)
   - ユーザーマニフェストのモデル設定 wizard → [tickets/tui-user-model-setup.md](tickets/tui-user-model-setup.md)
   - spawn 失敗時に Pod の stderr が TUI に表示されない → [tickets/tui-spawn-error-surface.md](tickets/tui-spawn-error-surface.md)
 - メモリ機構

tickets/tui-input-queue.md

@@ -1,38 +0,0 @@
-# TUI: Run 中の入力キューイング
-
-## 背景
-
-Pod は `Method::Run` を Run 中に受け取ると `AlreadyRunning` で即座に拒否する設計（1 turn = 1 message）。これはプログラマティックなクライアント（pod_cli、Pod 間通信の `sendToPod`）にとっては自然な契約だが、TUI で人間が操作している場合、「現ターンが終わるのを待って次を投げる」ためにユーザーが目視で完了を待つ必要があり、テンポが悪い。
-
-「次のターンが終わり次第すぐに投げる」を可能にしたい。
-
-## 方針
-
-**プロトコルには載せず、TUI クライアント側でキューを持つ。**
-
-理由：
-
-- キューイングは人間が連続入力する TUI 固有の都合。pod_cli や Pod 間通信は 1 turn = 1 message が自然で、不要な抽象を背負わせない。
-- キュー上のメッセージは「まだ送信していないユーザー入力」であり、送信前のキャンセル・編集が自然にできるべき。これは TUI ローカル状態で扱うのが素直。
-- Pod controller / protocol への変更が不要。他クライアントへの影響ゼロ。
-
-## 要件
-
-- Run 中に Enter で送信した入力は TUI 内のキューに積まれる（即座に Pod に送信されない）。
-- 現在の Run が `RunEnd` で終了したら、キュー先頭を `Method::Run` として送信する。
-- キューに積まれた状態がユーザーから見える（積まれていることが分かる UI 表現）。
-- キュー内のメッセージは送信前にキャンセル・編集できる。
-- Pause 中の Resume 入力との関係を整理する（Resume はキューイングではなく即座に発火、で良いはず）。
-- キャンセル（`Method::Cancel`）が走った場合、キューをどう扱うかを決める（破棄が妥当と思われるが要検討）。
-
-## 完了条件
-
-- TUI で Run 中に入力を送信すると、現ターン終了直後に自動で次が投げられる。
-- 積まれた状態と、送信前のキャンセル・編集ができる。
-- pod プロトコルや pod crate に変更が入っていない。
-
-## 範囲外
-
-- 複数 Pod 間でのキュー共有・転送
-- キューの永続化（TUI 再起動をまたぐ保存）
-- キュー内メッセージの優先度・並び替え（FIFO で十分）