fix(cli): delete a word with Ctrl+Backspace

[TTyChud]

Ctrl+Backspace now deletes a word in the composer. Before, it did nothing.

This is muscle memory: in a terminal, Ctrl+Backspace is what people reach for to delete a word, and other coding agents (opencode, hermes, and most terminal UIs) already do it. Here Ctrl+W was the only way.

The change is two lines in cli/src/components/multiline-input.tsx. The word-delete branch matched Alt+Backspace or Ctrl+W, and the plain-Backspace branch ignores any ctrl, so Ctrl+Backspace fell through both. It now matches:

(key.name === 'backspace' && (isAltLikeModifier || key.ctrl))

That's all — the key already arrives from OpenTUI as Ctrl+Backspace, so only the check was missing. Alt+Backspace, Ctrl+W, and plain Backspace behave exactly as before.

One limit: on terminals that send Ctrl+Backspace in a way that can't be told apart from a plain Backspace, it still deletes one character. Nothing to do about that.

Overlaps #1225 and #1182, which touch the same handlers; neither adds this binding.

[codebuff-team]

Good, minimal fix. The diagnosis is correct: the word-delete branch only checked isAltLikeModifier, so Ctrl+Backspace fell through to the plain-backspace case. Adding || key.ctrl to that condition is the right, minimal fix, and it doesn't disturb the existing Alt+Backspace or Ctrl+W paths.

A couple of things worth double-checking before this lands upstream:

• Does key.ctrl ever fire for keys where you don't want word-delete semantics, e.g. some terminal emulators sending Ctrl+H as backspace with ctrl set for unrelated reasons? Worth a quick sanity check across iTerm/tmux/Windows Terminal if you have access, since keyboard-handling PRs are exactly the kind of thing that regress silently on one terminal while fixing another.
• No test changes. If cli/src/components/multiline-input.tsx has any existing key-handling tests (worth checking cli/src/components/__tests__ or similar), adding a case for Ctrl+Backspace would make this easy to keep passing through refactors like the ones in Compute word and line boundaries lazily in MultilineInput key handlers #1225/fix(cli): support ctrl-arrow word navigation #1182 that you flagged as overlapping.

Substance is sound and the diff is small enough to review in seconds. Flagging as needs-work only for the missing test coverage, not the fix itself — happy to see this ported as-is if the maintainers don't consider a test necessary for a two-line key-matching change.