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

[c8dhjp4tyv-bit]

Recreated on the rewritten main after #1103 was auto-closed during repository maintenance. This carries the final reviewed branch state onto the new history while preserving upstream changes added after the rewrite.

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
• retain the focused idle-attachment handoff regression added after review on the original PR

Fixes #1052

Validation

Prior validation before the history rewrite:

• 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

The port onto rewritten main was three-way applied. Five files applied cleanly; the only drifted file was command-registry.ts, where the /btw hunk was reapplied while preserving the new upstream buildSkillPrompt import.

[codebuff-team]

This is a solid, self-contained feature. buildBtwPrompt in prompt-builders.ts mirrors the existing pattern used by /plan and /review, and the command handler in command-registry.ts correctly branches on isStreaming/streamMessageIdRef/isChainInProgressRef to decide between queuing and sending directly — reusing capturePendingAttachments() rather than duplicating attachment-handling logic is the right call.

The tests are a real strength: btw-attachments.test.ts and the additions to command-args.test.ts cover the three meaningful branches (busy+attachments, idle+send, empty-args usage message), and the comment explaining why sendMessage intentionally receives no explicit attachments argument (relying on prepareUserMessage's fallback to pendingAttachments) is a good call-out for future maintainers who might otherwise 'fix' that as a bug.

A couple of things worth double-checking before porting:

• In the busy branch, params.inputRef.current?.focus() is called right after setInputFocused(true) — confirm this doesn't fight with any focus management already happening in clearInput.
• rawInput is captured from params.inputValue.trim() before clearInput runs, so history saves the full /btw ... text; that matches existing command conventions but worth a sanity check against how /plan//review save history for consistency.

Nothing here touches forbidden paths, and the change is additive and narrow. Nice work reconstructing this cleanly after the history rewrite — the PR description's account of the three-way apply is helpful context for review.

[c8dhjp4tyv-bit]

Added regression assertions for both sanity checks. The busy /btw path now proves the full /btw ... command is saved to history, setInputFocused(true) is requested, and the imperative input focus() is called exactly once after the input is cleared/queued. The existing attachment handoff assertions remain. Targeted command/prompt/attachment suites: 27 passed, 0 failed.