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.