OMP 启动键盘能力查询¶

OMP 的 ProcessTerminal 在选择其键盘编码之前，会先发送 CSI ? u，然后发送一个 DA1 哨兵。新的桌面终端已经宣告 Kitty 支持，但直接 New Tab 启动可能会在该渲染器拥有回复权之前发起查询。此前，启动入口仅回复 OSC 颜色查询。

渲染器现在会根据其实际的 xterm vtExtensions.kittyKeyboard 设置，提供可选的 terminalKittyKeyboardProtocol: true。现有的本地/SSH/配对生成路径会将其作为可选的 kittyKeyboardProtocol 放入启动入口中。缺失或为 false 的能力不会改变行为，包括在原生 Windows 上故意不启用 Kitty 的窗格。入口版本和流操作码保持不变。终端创建接受附加字段，但主机权威的 terminal.createAgentSession 和 terminal.ensureAgentSession 使用严格模式。客户端仅在主机会宣告 agent-session.keyboard.v1 之后，才在这些方法上发送键盘标志。协商后的负载在启动重试之间保持不变；旧主机接收原始负载并保留渲染器回退。新主机接受省略该标志的旧客户端。配对后台启动使用相同的协商支持和默认配对终端宣告；旧版终端创建接收附加标志。

源入口仅在其截止时间/渲染器交接之前回复确切的第一个 CSI ? u。它使用现有的模式跟踪器处理前面的标志推送，并使用现有的回复投递回显保护。其转换后的源跨度仅消费一次该查询，而随后的 DA1 和 Kitty 模式设置字节保留其序列范围并到达渲染器。键盘意图不需要主题颜色。颜色和 Kitty 权限独立结束：回复两种颜色并不会结束 Kitty 处理，ConPTY 的持久颜色所有权也不会在交接后保留 Kitty 所有权。

使用只读参考检出运行实际的 OMP 协议冒烟测试：

ORCA_BACKGROUND_LAUNCH=1 bun tests/tools/omp-startup-keyboard-smoke.mjs /path/to/oh-my-pi > /tmp/omp-startup-keyboard.json

这使用 OMP 的真实 ProcessTerminal，拦截进程本地 stdin/stdout，使用一个可丢弃的 HOME，并且没有模型调用。它验证在任何渲染器附加之前完成协商、单次回复、保留的模式推送以及连续的原始序列覆盖。它不构成实时 Windows/SSH 或已渲染快捷键证明。