fix(cli): support ctrl-arrow word navigation

[c8dhjp4tyv-bit]

Recreated on the rewritten main after #1108 was auto-closed during repository maintenance. This carries the same reviewed change set on the new history.

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

Prior validation before the history rewrite:

• 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]

Good, well-scoped change. Extracting findPreviousWordBoundary/findNextWordBoundary into cli/src/utils/word-navigation.ts and adding getWordNavigationPosition is a sensible refactor that lets Ctrl+Left/Right reuse the same boundary logic as Alt+Left/Right/B/F. The guard isCtrlArrow = key.ctrl && !key.meta && !key.option correctly keeps Ctrl+B/Ctrl+F as single-character Emacs movement instead of reclassifying them as word navigation, which is the subtle part of this fix and is called out explicitly in the comment.

The test file (word-navigation.test.ts) covers the meaningful branches: Ctrl+Left/Right, Alt equivalents, non-word-nav arrows, and the Ctrl+B/F exclusion. That's proportionate coverage for a ~70-line pure-logic module.

One thing worth double-checking before porting: isAltLikeModifier is computed by the caller (isAltModifier(key) in multiline-input.tsx) and passed in, while isCtrlArrow is computed independently inside getWordNavigationPosition from the raw key. Worth confirming these two paths can't both fire for the same chord on some terminal (e.g., a terminal that sends ctrl+alt+left for something else) - the meta/option exclusion appears to defend against that, but it'd be good to see this exercised against real terminal key events, not just synthetic key objects, given how fiddly the OpenTUI/terminal key-encoding matrix is. That's a nit rather than a blocker.

Overall this is a targeted, well-tested fix for a real gap (#847) and should port cleanly.

[c8dhjp4tyv-bit]

Addressed the terminal-chord sanity check. I added explicit regression coverage for mixed Ctrl+Alt/Option arrow events: they are not reclassified as plain Ctrl+Arrow when the caller does not identify an Alt-like modifier, and when the caller does, the chord is routed only through the existing Alt path. Targeted result: 7 passed, 0 failed.