feat: add readline editing keys to text input

[ronload]

Text inputs (the add/edit dialog, / search, the command palette, and the project/context prompts) only handled the basic key set: Backspace, Delete, arrows, Home/End, and printable characters. Control chords fell through to the
character-insert path, so Ctrl+H typed an h instead of deleting, and none of the usual readline editing keys worked.

This adds the common readline editing set to every text input, routed through the existing apply_to_draft choke point so all four contexts stay in sync.

Changes

• New keys, available in any text input:
  • Ctrl+A / Ctrl+E: move to start / end of line
  • Ctrl+B / Ctrl+F: move one character left / right
  • Alt+B / Alt+F: move one word left / right
  • Ctrl+H: delete character before the cursor; Ctrl+D: delete character under the cursor
  • Ctrl+W: delete the word before the cursor; Alt+D: delete the word after the cursor
  • Ctrl+U: delete to start of line; Ctrl+K: delete to end of line
• Model each keystroke as an EditAction resolved by resolve_edit_key. Ctrl/Alt chords are matched before the insert arm, so an unmapped chord (e.g. Ctrl+G) is swallowed rather than typed as a literal letter, this is the actual fix for the Ctrl+H behavior.
• A chord fires only when exactly one of Ctrl/Alt is held. AltGr is reported as CONTROL | ALT on international layouts, so it falls through to text insert and still types € and friends.
• Ctrl+N / Ctrl+P are deliberately left unmapped: upstream handlers reserve them for popup and list navigation.
• Three new DraftState primitives (delete_word_backward, kill_to_start, kill_to_end) with multibyte char-boundary handling, plus unit and resolver tests.

All existing tests pass; cargo clippy --all-targets and cargo fmt --check are clean.

Note: I kept this scoped to behavior and left the README keybinding tables out for now, happy to add an Insert mode key table to the "Edit dialog" section in this PR if you'd prefer it bundled. I also intentionally did not enable the kitty keyboard protocol: none of these keys need it, and it would add terminal-capability detection and teardown for no functional gain here. Can revisit separately if a future binding ever needs it.