扩展按键（Kitty/csi-u）模式下 Emacs/readline 编辑键（Ctrl+H/P/N 等）集体失效 || Emacs/readline editing keys (Ctrl+H/P/N…) all dead when extended keys (kitty/csi-u) are enabled

版本与环境 / Environment

• Kimi Code 版本: 0.38.0（~/.kimi-code/bin/kimi）
• 系统: macOS，终端 Ghostty（支持 Kitty keyboard protocol）
• 复现于 tmux 3.7c 中：set -g extended-keys on + set -g extended-keys-format csi-u
  （即按 TUI 启动警告的建议开启扩展按键后）

问题现象 / Problem

终端以 Kitty keyboard protocol 上报按键时，输入框中的 Emacs/readline 编辑快捷键集体失效：

• Ctrl+H（向左删除字符）无反应
• Ctrl+P / Ctrl+N（上/下一条历史）无反应
• 推测其余未显式绑定的 Ctrl+字母 组合（A/E/B/F/U/K/W/D/T/R 等）同样失效

将 tmux 改回 extended-keys off 并重启 Kimi Code 后，以上按键全部恢复正常。
（Ctrl+C / Ctrl+V / Ctrl+X 等 TUI 显式绑定的组合键在两种模式下均正常。）

复现步骤 / Reproduction

1. Ghostty 中运行 tmux，配置 set -g extended-keys on 和 set -g extended-keys-format csi-u，重启 tmux
2. 启动 kimi，在输入框输入任意文字
3. 按 Ctrl+H / Ctrl+P / Ctrl+N —— 均无任何动作

期望行为 / Expected

无论终端是否启用扩展按键，这些编辑键的行为与传统编码路径一致。
建议在 csi-u 解码层将 ESC[<code>;5u 形式的 Ctrl+字母 规范化映射到与 legacy
控制字节相同的动作（Ctrl+H=退格、Ctrl+P/N=历史、Ctrl+A/E=行首/行尾……），
或开放自定义键位（相关：#1524）。

原因分析 / Analysis

Kitty disambiguate 模式会把所有 Ctrl+字母 统一编码为 CSI u 序列
（如 Ctrl+H→ESC[104;5u、Ctrl+P→ESC[112;5u），与 \x08、\x10 等 legacy
字节彻底分离——这正是该协议的设计目的。Kimi Code 只给显式用到的组合键
（Ctrl+C/V/X 等）编写了绑定；在扩展按键路径下，未绑定的 Ctrl+字母 成为
"未知键"被丢弃，而在 legacy 路径下它们以控制字节形式被输入层正确识别。

已用 tmux 中间人实测验证：tmux 正确地将 Ctrl+H 以 csi-u 转发给 pane 内程序，
问题在 TUI 侧缺少映射，与终端/tmux 无关。

同类输入层问题参考：#704（Backspace 删除两字符）、#1984（异常退出后 Kitty
模式残留）、#256（Shift+Enter 无法换行）。

临时规避 / Workaround

tmux 中保持 extended-keys off（代价：失去 Shift+Enter 等扩展按键能力）。

Reproduce the issue with tmux using extended-keys and csi-u, then locate the TUI input decoder and key-binding handling for CSI u sequences. Verify the relevant Ctrl-letter sequences are normalized like their legacy control-byte counterparts, and add or run coverage showing Ctrl+H/P/N and the other listed editing keys work with extended keys enabled.