🤖 fix: Ctrl+C no longer interrupts stream when text is selected

[deansheather]

Previously, Ctrl+C would interrupt the stream if the user was not in an editable element, even if they had text selected elsewhere in the chat (e.g., in message content).

Problem

The condition (!inEditableElement || !hasSelection) would interrupt when:

• NOT in editable element (regardless of selection) ← the bug
• In editable element but no selection

This meant selecting text in chat messages and pressing Ctrl+C to copy would incorrectly interrupt the stream.

Solution

Simplified the logic to !hasSelection - now it always checks for text selection anywhere on the page, regardless of whether the user is in an editable element.

Verification

// Before: Interrupted even with selection outside editable elements
if ((canInterrupt || showRetryBarrier) && (!inEditableElement || !hasSelection)) {
  // interrupt
}

// After: Only interrupts when nothing is selected
if ((canInterrupt || showRetryBarrier) && !hasSelection) {
  // interrupt
}

Behavior now:

• User selects text in chat messages → Press Ctrl+C → Text is copied (stream continues) ✅
• No text selected → Press Ctrl+C → Stream is interrupted ✅

Generated with cmux

[deansheather]

Closing as redundant - PR #562 solved this issue in a better way by introducing vim-aware keybinds.

The original problem (Ctrl+C interrupting when text is selected) is now resolved:

• Vim mode: Ctrl+C always interrupts (expected - vim users use yank for copy)
• Non-vim mode: Esc interrupts, Ctrl+C is for copying

This is a cleaner solution that provides the most natural behavior for each mode.