把「发送/换行」做成可配置键位：Enter 换行、Ctrl+Enter 发送

[Junikusam4]

环境：DSH Desktop 0.1.7-rc.2（Windows），客户端包来自 resources/app.asar 里的 @deepseek-ai/dsh-client-ui-conversation。

现状：对话框的 Enter 语义是写死的。lib/client.js 里 Lexical 的 KEY_ENTER_COMMAND：

if (event?.shiftKey === true) return false;                 // Shift+Enter → 交给编辑器插换行
if (handlers.arbitrate("enter", false) !== "pass") {        // 斜杠菜单等弹层优先吃掉 Enter
  event?.preventDefault(); return true;
}
event?.preventDefault();
if (!handlers.canSubmit()) return true;
handlers.submit(event?.ctrlKey === true || event?.metaKey === true);   // 普通 Enter 就是发送

即：普通 Enter = 发送，Shift+Enter = 换行，Ctrl/Cmd+Enter = 加速手势（忙碌时是 busyEnter 的反面）。设置里能调的只有「忙碌时 Enter 是排队还是插入」（设置 → 通用 的 composer-enter 行，字段 busyEnter），没有「Enter 是发送还是换行」这一项。

问题：很多人的肌肉记忆是 Enter 换行、Ctrl+Enter 发送——VS Code、Slack、飞书、微信桌面版都是这个键位，写长 prompt 时尤其明显：每写一行都要伸手够 Shift。目前用户只有两条路，都不理想：

1. 改打包产物 app.asar 里那 712 KB 的 client.js——Desktop 是打包发布 + 自动更新，改了会被覆盖；
2. 写插件从外部拦截按键（capture 阶段 keydown → preventDefault + stopImmediatePropagation → 注入 insertLineBreak）。能做（我本地就是这么绕的），但输入法组合态、/ 命令菜单抢 Enter、其它编辑器实例这些边界情况都得靠启发式判断，稳定性不如一个官方设置项。

建议：在已有的 ui-conversation 设置命名空间里加一个字段（例如 enterBehavior: "send" | "newline"，默认 "send" 保持现行为），并复用现在只放了 busyEnter 的 composer-enter 行，加一个二选一控件：

• 「Enter 发送，Shift+Enter 换行」（当前默认）
• 「Enter 换行，Ctrl+Enter 发送」

为什么改动很小：shiftKey === true 本来就是「插换行」分支，handlers.submit(accelerated) 本来就区分普通手势和 Ctrl/Cmd 手势；真正要动的只有「普通 Enter 走插换行还是走提交」这一处判断，加上一个设置字段和一个控件。busyEnter（排队/插入）语义独立，建议保持不变，默认值也不变，老用户无感。

附带期望：设置搜索里能命中「Enter」「换行」「发送」这些词——现在只能搜到「忙碌时行为」，用户很难发现按键语义其实不可配。

---

English summary

Feature request: make the composer submit/newline keymap configurable.

Today the composer keymap is fixed in @deepseek-ai/dsh-client-ui-conversation: plain Enter submits, Shift+Enter inserts a line break, and Ctrl/Cmd+Enter is the accelerated chord (the complement of busyEnter while busy). Settings only expose busyEnter (queue | steer) on the composer-enter row — there is no "Enter sends vs. Enter breaks the line" option.

Many users expect Enter = newline, Ctrl+Enter = send (VS Code, Slack, Feishu, and most chat clients), which matters a lot when writing long prompts; today they must either patch the packed app.asar (lost on every auto-update) or intercept keydown from a plugin with heuristics for IME composition and for Enter-owning popups such as the / menu.

Suggestion: add a field such as enterBehavior: "send" | "newline" (default "send") to the existing ui-conversation settings namespace, and surface it next to busyEnter on the composer-enter row:

• "Enter sends, Shift+Enter breaks the line" (current default)
• "Enter breaks the line, Ctrl+Enter sends"

The change is small: shiftKey === true already routes to line-break and submit(accelerated) already distinguishes the plain from the accelerated gesture, so only the plain-Enter branch plus one settings field and one control are needed. Keeping busyEnter untouched and the default unchanged makes it a no-op for existing users.