Windows: headless dsh web host is killed by stray CTRL_C_EVENT from tool children (exit 130), all sessions die silently

[Xizhi1024]

dsh web 宿主进程在 Windows 上被工具子进程的杂散 CTRL_C_EVENT 误杀（exit 130），整站会话全部中断

复现、预期与验收

• 复现步骤：
  1. Windows 上以无 TTY 方式启动 dsh web（例如 VS Code 扩展以 stdio ignore / 隐藏控制台拉起，或任何后台服务化启动），宿主内保持一个活跃会话。
  2. 在会话里让任意工具子进程发出控制台 Ctrl+C 事件。最简单的等价物：宿主内执行 python -c "import os, signal; os.kill(0, signal.CTRL_C_EVENT)"（pytest / multiprocessing / sendevent 等工具的惯用行为同样会发 CTRL_C_EVENT）。
  3. 事件广播给共享隐藏控制台的全部进程，宿主也收到 SIGINT。
• 实际结果：apps/cli/src/profile-boot.ts 的 process.on('SIGINT', () => interrupt(130)) 不区分「有终端的交互启动」与「无终端的服务启动」，一律走优雅退出。宿主进程以 exit code 130 静默消失，所有进行中的会话、后台作业、子 agent 同时中断，且 stdio 被丢弃时无任何崩溃痕迹（无堆栈、无日志、无 OS 崩溃记录），从外部看就是「意外退出」。
  • 实测取证（rc.6 + Windows 11 + VS Code sidebar 扩展）：宿主 pid 45844 启动 83 秒后被 CTRL_C_EVENT 命中，日志仅剩 unexpected exit pid=45844 code=130 signal=null；Prefetch 排除了 taskkill/硬杀路径。latest（0.1.0-rc.7, 99f6f02）同一段代码未变，未修。
• 预期结果：无 TTY 的服务态宿主不应把控制台广播的 SIGINT 当作用户中断。交互式终端里的 Ctrl+C 行为保持不变；SIGTERM / taskkill / appExit 等管理通道不受影响。
• 环境：Windows 11 24H2；@deepseek-ai/dsh 0.1.0-rc.6（复现）与 0.1.0-rc.7（代码审阅确认未修）；宿主由 VS Code 扩展以隐藏控制台 + stdio ignore 拉起。
• 验收条件：
  1. 无 TTY 启动的 dsh web 在收到杂散 CTRL_C_EVENT 后继续运行（可记一行日志说明已忽略）。
  2. 终端交互启动时 Ctrl+C 仍然中断退出（exit 130 语义保留）。
  3. 回归覆盖：Windows 上服务态宿主 + 子进程 CTRL_C_EVENT 的用例。

建议修复方向（已本地验证可用）：在 SIGINT 处理器里判别服务态，例如

process.on('SIGINT', () => {
  if (!process.stdout.isTTY) {
    process.stderr.write('[dsh] SIGINT ignored in headless service context (shared-console ctrl event)\n')
    return
  }
  interrupt(130)
})

更彻底的方向是让 Windows 上无 TTY 宿主创建独立进程组（CREATE_NEW_PROCESS_GROUP / new process group）或给工具子进程断开控制台继承，使子进程的 CTRL_C_EVENT 不再广播到宿主；但 isTTY 判别是最小且无行为回退的止血。

[Xizhi1024]

确定性复现确认（pristine 0.1.0-rc.7，npm tarball 全新解压）。

用一个自身 SIGINT-忽略的 Python 监督者拉起无 TTY 宿主（stdout 重定向文件、共享控制台），待 HTTP 就绪后发一次 CTRL_C_EVENT：

import os, signal, subprocess, time, json, urllib.request
signal.signal(signal.SIGINT, signal.SIG_IGN)
p = subprocess.Popen(['node', 'lib/bin.js', '--profile', 'web', '--host', '127.0.0.1', '--port', '3999'],
                     stdout=open('boot.log', 'w'), stderr=subprocess.STDOUT)  # 无 TTY
for _ in range(30):
    time.sleep(1)
    try: urllib.request.urlopen('http://127.0.0.1:3999', timeout=2); break
    except Exception: pass
os.kill(0, signal.CTRL_C_EVENT)   # 广播到共享控制台
time.sleep(4)
print(json.dumps({'alive_after': p.poll() is None, 'exit_code': p.poll()}))

结果：

{"booted": true, "pid": 11888, "alive_after": false, "exit_code": 130}

与生产事故签名完全一致（静默消失、exit 130、无堆栈）。

复现前提（重要）：宿主与发射进程须共享同一控制台。同机对照实验：用 Start-Process -WindowStyle Hidden（新独立控制台）拉起的实例在同一场事件下存活——这既解释了为何该问题只在「扩展拉起/后台服务化」等共享隐藏控制台形态下出现，也印证了报告里 CREATE_NEW_PROCESS_GROUP / 独立控制台方向可根治。