[UX Feedback] Improve background task lifecycle, streaming output, shell persistence and tool capability visibility

在使用 Kimi Code 进行远程服务器部署和长任务执行时，遇到了一些工具层面的体验问题。整体能力很强，但部分行为存在语义不明确、状态不可见的问题，容易让用户误判任务状态，甚至导致部署流程卡死。
以下是几个比较明显的问题和改进建议。

1. TaskStop 行为容易产生误解：停止本地任务 ≠ 停止远程任务
   Problem
   在通过 SSH 执行远程部署任务时，我启动了一个后台任务（例如 Docker Compose 部署）。
   之后调用 TaskStop 停止任务时，实际效果只是结束了本地 SSH 会话/客户端等待状态，但远程服务器上的进程仍然继续运行。
   结果：
   第一个 SSH 会话退出，但远端 compose 进程仍在运行
   后续命令启动新的部署流程，与旧任务产生冲突
   服务端口被占用，导致部署异常
   用户看到的现象是“AI 把任务搞挂了”
   Expected behavior
   TaskStop 应该明确提示：
   This only stops the local task watcher/session. The remote process may continue running.
   或者提供选项：
   Stop local monitoring only
   Kill remote process
   Send termination signal via SSH
   目前的问题是：工具语义和用户直觉不一致。
2. 长时间任务缺少阶段性状态反馈
   Problem
   Docker build、依赖安装、部署等任务可能运行十几分钟。
   当前后台任务状态通常只有：
   Task is still running
   用户无法知道：
   当前执行阶段
   是否卡住
   已完成多少
   下一步是什么
   同时 TaskOutput 又不建议频繁轮询，导致用户陷入：
   不轮询不知道状态，轮询又不推荐。
   Suggestions
   建议增加：
   自动 heartbeat
   阶段性状态更新
   简单进度事件
   例如：
   [10:20] Installing dependencies...
   [10:25] Building Docker image layer 12/30...
   [10:30] Starting containers...
   这样用户无需主动查询。
3. 流式输出缓冲导致任务状态误判
   Problem
   例如：
   ssh server "docker build ..." | tail -20
   由于管道缓冲，用户可能长时间看不到任何输出。
   实际情况：
   任务没有停止
   构建仍在运行
   输出只是没有实时刷新
   用户容易认为：
   卡死了。
   Suggestions
   工具层可以增强：
   SSH 输出实时 streaming
   自动检测 stdout buffering
   提供 incremental logs
   让用户看到真实执行状态，而不是等待最终结果。
4. SSH 会话缺少连接复用能力
   Problem
   每次 Bash 执行都是新的 shell：
   SSH handshake 重复执行
   网络环境不稳定时容易连接重置
   多次远程操作浪费大量时间
   部署流程中，大量时间消耗在：
   connect → authenticate → execute → disconnect
   Suggestions
   支持：
   SSH ControlMaster
   persistent shell session
   connection pooling
   类似：
   open remote session
   ↓
   execute multiple commands
   ↓
   close session
   可以明显提升远程开发体验。
5. 工具能力发现不足
   Problem
   用户无法清楚知道：
   当前启用了哪些 MCP
   哪些插件已经安装
   哪些工具当前可用
   哪些能力不可用
   例如：
   我看到系统存在 WebBridge 相关信息，因此自然会尝试调用，但实际无法确认：
   是否已启用
   是否有权限
   是否支持当前环境
   这会造成用户和 AI 对能力范围理解不一致。
   Suggestions
   增加类似：
   /tools
   或者：
   Environment capabilities:

✓ Browser
✓ Terminal
✓ GitHub
✗ WebBridge
✓ File tools
让能力边界透明。
6. Windows + Git Bash 环境兼容问题
Problem
Windows 环境下：
Git Bash 中：
pnpm
可能不在 PATH。
最终只能直接调用：
node_modules/.bin/tsc.CMD
虽然属于环境问题，但对于 AI Coding Agent 用户来说非常常见。
Suggestions
可以增加：
Windows PATH 自动检测
pnpm/npm/yarn 可执行文件探测
fallback 到 node_modules/.bin

The issue names no files, tests, or entry points. First map the CLI's task lifecycle, streaming output, SSH session handling, capability discovery, and Windows command resolution, then split the six suggestions into separately testable changes with explicit completion criteria.