fix(cli): queue /plan, /interview, /review mid-turn instead of interrupting - #1256

Please codebuff-team merge this PR, i need this fix, and thank you @kavish-19 for tha patch

Good bug fix. The diagnosis is correct: /plan, /interview, and /review bypassed the busy-check that /skill:<name> already implements via dispatchSkillPrompt, so firing one of these mid-turn hit sendMessage() directly and force-stopped the in-flight run through registerActiveRun. Extracting that logic into sendOrQueuePrompt() in command-registry.ts and routing all six call sites (three command handlers + three router input-mode paths) through it is the right fix — it matches the pattern already established for plain-text and skill submits, and it closes off future drift by having dispatchSkillPrompt become a thin wrapper over the shared helper.

The test additions in router-steering.test.ts are appropriate: they cover both entry paths (inline args and input-mode submit) for all three commands, both busy and idle, and assert on sendMessage/addToQueue call counts rather than just presence, which would have caught this bug before it shipped.

One thing worth double-checking before porting: sendOrQueuePrompt now takes an attachments parameter defaulting to [] for the plan/interview/review paths, while dispatchSkillPrompt passes capturePendingAttachments(). Confirm that plan/interview/review intentionally don't need pending attachments captured — if a user has staged image/file attachments before typing /plan foo, this change would silently drop them where the old code (which also didn't capture attachments) had the same gap, so it's not a regression, but it's worth a comment or a follow-up since the two call sites now diverge in an unobvious way.

Small, well-scoped, tested, and addresses a real filed complaint (#1211). This is a solid first PR.

Good catch on the attachments question — I checked it and it turned up two real defects, one of them introduced by this PR. Pushed a fix in dffc4bf.

The mechanism is in prepareUserMessage (cli/src/hooks/helpers/send-message.ts:151):

const allAttachments = attachments ?? useChatStore.getState().pendingAttachments

Passing an explicit array suppresses the pendingAttachments fallback; passing no key at all uses it. sendOrQueuePrompt had that backwards on both branches:

1. Queue branch defaulted to []. A mid-turn /plan, /interview or /review queued with no attachments and left the staged ones in the store — and the queue drain passes attachments: message.attachments explicitly (cli/src/contexts/chat-runtime-context.tsx:131), so they aren't picked up there either. They stay staged and land on whatever the user sends next.

   One correction to your read: this was a regression, not the same gap the old code had. Pre-PR, /plan <text> mid-turn called sendMessage({ content, agentMode }) with no attachments key, so the fallback attached them to the plan message. Routing those paths onto the queue is what suppressed it. Worth flagging since "not a regression" is the part that would have let it through the port.

2. dispatchSkillPrompt passed capturePendingAttachments() as an argument, so it evaluated before the busy check. An idle /skill:<name> cleared the store and then called sendMessage without the captured value — attachments dropped outright. That one is on me, and it's the more visible of the two.

Both are fixed by capturing inside the queue branch, where the skill path already had it, and dropping the parameter so neither call site can reintroduce the split. dispatchSkillPrompt stays a thin wrapper.

Verification: both new tests confirmed red against 0413433 before the fix, green after (15 pass / 0 fail in router-steering.test.ts). Full suite is 39 failures, identical to the pre-change baseline — no new ones. tsc --noEmit clean on the touched files. command-registry.ts still fails prettier --check, but it does so on unmodified main too, so I've left it rather than bury the diff in an unrelated reformat.