[Qiyuanqiii]

中文输入法选词时按回车是“确认候选词”，但它在三个输入框里同时被当成提交：命令面板会立刻执行高亮命令并收起面板，项目文件夹路径框会把还没写完的路径当成最终值锁定、并用截断的目录名替项目命名，供应商设置的“手动添加模型”会合并半截候选词再清空输入框。三处 onKeyDown 都只判 event.key === "Enter"，没有组合期守卫。

补上仓库既有的守卫 event.nativeEvent.isComposing || event.keyCode === 229（lib/composer-keyboard.ts:5、v2/components/markdown-input.tsx:136、v2/components/keyboard-settings.tsx:51、v2/chat-preferences.ts:74，以及命令面板自己的 Ctrl+K 处理都是这个式子）。必须读 nativeEvent：React 的 SyntheticKeyboardEvent 不复制 isComposing，写成 event.isComposing 在浏览器和 jsdom 里都恒为 false，守卫等于没写。这一条是实跑出来的：先用 event.isComposing 写的版本三条用例全红，换成 nativeEvent 才变成预期的红/绿。

口径：非测试代码里 key === "Enter" / key !== "Enter" 判定共 6 处、分布在 5 个文件，修复前缺守卫的是本次这 3 处，修复后 6/6 一致。isComposing 与 keyCode === 229 两个半边都留着：每条用例分别投递 isComposing: true 和 keyCode: 229 两种事件，所以两个条件都有实际覆盖，不是冗余死分支。Escape 与方向键在组合期仍不加守卫——它们不执行动作，最坏只是高亮项移动或面板收起，且候选词行为无法在无 WebView2 的环境验证，故不在本 PR 扩大范围。表单原生提交路径（composer 走 requestSubmit）不受影响，浏览器在组合期不会用回车提交表单。

验证：

• 三条新用例在 origin/main 上失败、在本修复后通过：同一组文件旧实现 3 failed / 66 passed，新实现 69 passed。用例断言的是组合期 Enter 不触发动作、面板与路径编辑框保持打开、项目名不被自动派生；{ key: "Enter" } 无守卫事件仍照常执行，所以不是把功能一起关掉。
• npm test 全量通过：259 个测试文件 / 2511 项（基线 2508 项 + 本次 3 条）。npm run typecheck、npm run check:api、npm run build 通过，git diff --check 干净。
• OCR delegate 复核（开 PR 前执行）：ocr delegate preview --from origin/main --to HEAD 给出 3 个可复核文件 / 共 6 个改动文件（merge_base 513c9510，+59/-7），三个 .test.tsx 被默认路径规则排除，已另行人工复核；三个文件命中 ocr delegate rule 返回的同一个规则组（system / **/*.{ts,js,tsx,jsx,mjs,cjs}），逐项核对拼写、死代码、硬编码、Hooks 层级与依赖、严格等号、异步错误处理与 XSS/eval 类安全条目，无发现。
• CI 结果以本 PR 的实际运行为准。需要说明的是 main 的 TypeScript console 在 Audit dependencies 步骤上已有红灯（dompurify/@vitest/mocker 共 4 条公告，见 fix(ui): 终端关闭响应迟到时保留新的会话绑定 #479 正文的对比记录），本 PR 不含依赖变更，不会让它变好也不会变坏。
• 证据边界：jsdom 无法表示“尚未上屏的候选词文本”，因此用例证明的是 Enter 在组合期不触发动作，而不是候选词能正确写入输入框；真实 WebView2 输入法的组合期行为没有做桌面端真机验收。

无 Surface 变化；不含凭据与本地运行数据；不触碰权限、Scope、沙箱与持久化边界；行为修正局限于三个输入框的按键处理，README.md 与项目记忆无需更新。