feat(cli): add a non-interrupting /btw command

[c8dhjp4tyv-bit]

Summary

• add /btw <additional thought> to send context without interrupting an active turn
• reuse the existing queue while preserving pending attachments
• send directly when idle and show usage for an empty note
• add slash-command metadata and regression tests

Fixes #1052

Validation

• targeted prompt, command, and router tests: 81 passed
• full CLI suite: 2,368 passed, 9 skipped
• full suite still reports 34 existing release-wrapper failures and 32 environment/harness errors
• CLI typecheck reaches existing missing tar and react-dom/server declarations; no errors point to the changed files
• git diff --check passed

[codebuff-team]

Nice work overall — this follows the existing /plan//review command patterns closely, adds a dedicated buildBtwPrompt in prompt-builders.ts, registers the command via defineCommandWithArgs, and includes solid regression coverage in command-args.test.ts and prompt-builders.test.ts. The empty-input usage message and busy-vs-idle branching in command-registry.ts are clean and readable.

One real gap: in the busy path you call capturePendingAttachments() and forward it to params.addToQueue(btwPrompt, pendingAttachments), preserving any attached files. But in the idle path (params.sendMessage({ content: btwPrompt, agentMode: params.agentMode })), pending attachments are never captured or attached at all. If a user has staged an image or text attachment and fires /btw while the CLI is idle, that attachment is silently dropped instead of being sent or queued. Given the PR's own stated goal — 'reuse the existing queue while preserving pending attachments' — this asymmetry looks like an unintentional oversight rather than a deliberate design choice, and it's untested (the idle-path test only checks the sendMessage call args, not attachment state).

Worth a quick fix: capture and pass pending attachments in the idle branch too (mirroring whatever the other direct-send commands do with attachments, if any), and add a test asserting attachments aren't lost when sent immediately. Once that's addressed this looks portable.

[c8dhjp4tyv-bit]

I traced the idle path through the actual SendMessageFn implementation. The attachment is not dropped: prepareUserMessage() in cli/src/hooks/helpers/send-message.ts does attachments ?? useChatStore.getState().pendingAttachments, then clears the store only after capturing those pending attachments. So an idle /btw direct send intentionally relies on the same fallback used by ordinary direct sends.

I added focused regression coverage in 7df9fb3 to make that handoff explicit: /btw leaves staged attachments untouched in the idle command path so sendMessage can consume them, while the existing busy-path test still verifies the queue captures and clears them itself.

I did not add a second capturePendingAttachments() in the idle command because that would duplicate attachment ownership that already belongs to sendMessage; the new test pins the intended contract instead.