No support for word-navigation shortcuts (option/alt + ←/→, option/alt + b/f) #696

option + ←/→ and option + b/f on macOS (alt + ←/→ and alt + b/f on Linux/Windows)
are the standard word-wise cursor navigation shortcuts on the command line.
Default readline (emacs-mode) bindings: \eb → backward-word, \ef →
forward-word. Work in iTerm, Ghostty, Terminal.app with default shell configs.

In Orca's terminal (v1.2.2-rc.2), option/alt + ←/→ emits the
xterm CSI sequence \e[1;3D / \e[1;3C, which default readline does not bind to
word-nav — so the cursor does not move word-by-word and (depending on shell)
garbage may be inserted at the prompt. option+b and option+f work because
macOptionIsMeta is enabled and xterm.js emits \eb/\ef which readline binds by
default.

Repro:

1. In Orca's terminal, run cat
2. Press option + →
3. Observed in Orca: ^[[1;3C
   Observed in iTerm (Esc+ option-key mode) / Ghostty with same shell:
   ^[f

Context: same class of bug as #443 (ctrl+r, fixed in #453), #481 (ctrl+u),
#482 (ctrl+e), audited by #519. Word-navigation arrow keys were not covered
by the #519 allowlist.