fix(cli): fix YOLO mode message handling and sync wedge

[seibe]

Summary

Fixes a sync wedge (deadlock) between the CLI and App that occurred specifically in YOLO (bypass permissions) mode. Three interrelated issues caused messages to stop syncing.

Related issues

Addresses: #521, #446, #29, #206 — YOLO mode not working, permissions still being asked.
Related: #648 — YOLO preference not persisted (addressed separately by #689).

Comparison with similar PRs

• fix(permissions): resolve YOLO mode race condition (#521) #561 — fixes the permissionHandler race condition where handleToolCall() ignores its mode parameter, plus adds reset() fix. This is a valid general fix for YOLO mode (YOLO mode (bypassPermissions) not working - users still asked for permissions #521), but does not address the specific AskUserQuestion wedge: even with the mode parameter fixed, AskUserQuestion would still be auto-approved in YOLO mode, and the app would hang waiting for user input that never comes. This PR prevents the wedge at multiple layers: (1) disallows AskUserQuestion in the SDK's disallowedTools, (2) excludes it from auto-approval in permissionHandler.ts, and (3) fixes the downstream message pipeline (immediate forwarding, atomic queue operations, flush-before-turn-end) that also contributed to the wedge. fix(permissions): resolve YOLO mode race condition (#521) #561 and this PR are complementary — fix(permissions): resolve YOLO mode race condition (#521) #561 fixes the general mode priority race, this PR fixes the AskUserQuestion-specific deadlock and message pipeline issues.
• fix: reset permissionMode in handler reset() and add debug logging #523 — a strict subset of fix(permissions): resolve YOLO mode race condition (#521) #561 (only the reset() fix, no race condition fix, no tests). fix(permissions): resolve YOLO mode race condition (#521) #561 supersedes it.
• fix: prevent head-of-line blocking in OutgoingMessageQueue #699 — fixes OutgoingMessageQueue head-of-line blocking by skipping unreleased items. This PR takes a different approach: making the release-and-enqueue atomic within a single lock acquisition, which eliminates the race condition at its source rather than working around it. Both approaches have merit; this PR's atomic approach prevents the race entirely while fix: prevent head-of-line blocking in OutgoingMessageQueue #699's skip approach tolerates it.

Root causes addressed

1. AskUserQuestion auto-approved in YOLO mode: Claude could call AskUserQuestion while in bypass-permissions mode. The tool was silently auto-approved, but no real user existed to answer, causing the App to hang waiting for input that would never come. Fix: disallow AskUserQuestion in the SDK's disallowedTools list when in YOLO mode, and add a guard in permissionHandler.ts to exclude it from auto-approval.

2. Messages not forwarded until iterator advanced: opts.onMessage() was called inside the for await loop over Claude's output, but the loop could be blocked waiting for nextMessage() (user input). In YOLO auto-continuation mode, this meant assistant messages from completed turns were not synced to the App until the next turn started. Fix: introduce an onMessageReceived callback that fires immediately when messages are parsed from stdout, decoupled from the iterator consumer.

3. Race condition in outgoing message queue: Tool-call release and next-message enqueue were separate operations under separate lock acquisitions. A released delayed message could be sent before the new message was enqueued, causing ordering issues. Fix: consolidate releaseToolCallIds into the enqueue() call for atomic execution within a single lock.

4. Turn-end sent before messages flushed: The onReady callback signaled turn completion before the outgoing message queue was fully flushed. Fix: make onReady async and await messageQueue.flush() before closing the turn.

5. Outbox batch overflow: flushOutbox sent all pending messages in a single request. During fast YOLO auto-continuations, the outbox could accumulate more messages than practical for a single POST. Fix: drain the outbox in a loop with MAX_BATCH_SIZE = 100.

Changes by file

• claudeRemote.ts: Add AskUserQuestion to disallowedTools in bypass mode; introduce onMessageReceived for immediate forwarding; widen onReady to async
• claudeRemoteLauncher.ts: Atomic tool-call release via releaseToolCallIds on enqueue(); async onReady with queue flush
• query.ts: New onMessageReceived callback on Query class, fired during stdout parsing
• OutgoingMessageQueue.ts: Add releaseToolCallIds option to enqueue() for atomic release-and-enqueue
• permissionHandler.ts: Exclude AskUserQuestion from bypass auto-approval
• apiSession.ts: Drain outbox in batched loop with MAX_BATCH_SIZE = 100

Test plan

• Start a session in YOLO mode → Claude does not attempt AskUserQuestion
• YOLO mode auto-continuation → messages appear in App in real-time without delay
• Multi-turn YOLO session → no orphan turns, messages arrive in correct order
• Large batch of messages in quick succession → outbox drains completely