fix(cli): support ctrl-arrow word navigation

[c8dhjp4tyv-bit]

Summary

• support Ctrl+Left and Ctrl+Right word navigation in the CLI input
• keep existing Alt+Left/Right and Alt+B/F behavior on the same boundary helpers
• preserve Ctrl+B and Ctrl+F as single-character Emacs movement
• add focused regression coverage for Windows-style arrow navigation

Fixes #847

Validation

• targeted multiline-input and word-navigation tests: 77 passed
• related CLI keyboard/chat-input tests: 74 passed
• CLI typecheck: only existing missing tar and react-dom/server declarations remain
• git diff --check passes
• Prettier reports the pre-existing formatting drift in multiline-input.tsx; the base file has the same result

[codebuff-team]

Nice, focused change. Extracting findPreviousWordBoundary/findNextWordBoundary into cli/src/utils/word-navigation.ts and adding getWordNavigationPosition as the single source of truth for word-wise cursor movement is a sensible refactor, and it comes with real unit tests (word-navigation.test.ts) covering Alt, Ctrl, and the Ctrl+B/F exclusion case — that's the kind of coverage this repo would want for input-handling changes.

A couple of things worth double-checking before this lands in the private tree:

1. Please confirm Ctrl+Left/Right isn't already bound to something else in multiline-input.tsx (e.g. history navigation, line-boundary jumps) elsewhere in the keydown handler — the diff only shows the Alt block being replaced, and it'd be good to know there's no double-handling or shadowing further down in the function.
2. isCtrlArrow = key.ctrl && !key.meta && !key.option — worth a one-line comment on why option needs excluding (presumably because some terminals report Alt as option+ctrl combos on macOS?), otherwise a future reader will wonder if this is intentional or copy-paste caution.
3. The PR body claims Prettier drift is pre-existing — that's fine to mention but not something to fix here.

Overall this is well-scoped, in-scope (cli/), and the tests are appropriate. Recommending it be ported, pending a maintainer's quick check on point 1 above.

[c8dhjp4tyv-bit]

Checked the navigation handler end-to-end. There is no second Ctrl+Left/Right binding after the new word-navigation block: the later branches are Cmd+Left/Right (line boundaries), Ctrl+A/E, Ctrl+Home/End, Ctrl+B/F, and unmodified arrows. Because the word-navigation branch returns immediately, plain Ctrl+Left/Right is handled exactly once.

I also addressed the modifier-question in 9400ea0 with an inline comment: option/Alt-like chords are deliberately excluded from the Windows-style Ctrl+Arrow path because OpenTUI/terminals can expose Alt-like modifiers separately or in combination; those chords belong to the existing Alt path instead.

[victorxheng]

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.