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

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.

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.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.