feat(prompt): 支持按机器人批量设置零注入并自动回传结果

[deepcoldy]

为减少执行型 bot 的上下文干扰，新增按 bot 独立设置的零注入模式。自定义中心支持名称搜索、多选、批量开启与恢复；已有提示和技能配置保留，部分保存失败时只保留失败项供重试。

• promptInjection=none 只传任务正文及附件信息，跳过 Botmux 系统提示、身份信封、逐轮提醒、角色、白板、记忆和技能目录。模式随 Session 持久化冻结，配置变更仅影响新会话；恢复及 fork 沿用原模式，历史/外部 adopt 会话缺少快照时保留默认模式。
• 支持条件复用普通会话的最终回复采集能力，覆盖 Claude Code、Codex、TraeX、CoCo、Hermes、MTR、Pi、Oh My Pi、ebsd、Grok 的本地后端及本地 RPC 输入。普通群内可直接 @ 执行 bot，宿主自动回复当前会话。
• 已建立签名派单绑定的会话可自动回报原 lead：只去除框架生成的精确完成协议，每轮 final 回报一次，不自动判定任务完成。回报使用独立重试和 turn 幂等键；lead 离线或响应丢失不会重发子会话的回复卡，也不会重复追加 lead turn。
• Bot 名称依次采用自定义展示名、实时飞书名称、离线缓存和原配置名称，保存后的快照也保持名称。

影响范围：公共配置、Session 持久化、首轮/续轮/触发事件输入构建、worker/final 投递、派单回报和 Dashboard。默认模式保留既有行为；覆盖普通群/话题会话、选仓缓冲、冷恢复、fork、定时任务与文档评论入口。Linux 本地验证；macOS/Windows 和所有原生 CLI/终端后端组合未逐一实测。

限制：CLI 原生提示、项目 AGENTS.md 和用户自装技能仍由 CLI 管理，已有提示历史无法撤回。远端后端与 v3 workflow 暂不支持；仅 adopt 能采集 final 的 CLI 不据此开放整 bot 开关。共享目录仍有全局 botmux-* 技能时拒绝启动，不删除其他 bot 的文件。

已知派单边界：dispatch --into 向此前没有派单记录的普通消息追加任务，不会建立签名回报绑定。现场测试确认其接单成功，但完成指令仍保留、回报返回 dispatch_target_unavailable；此路径不能算零注入自动回报验证通过。普通协作使用直接 @，已有签名绑定的派单路径保留自动回报功能。

验证：

bun run test test/prompt-builder.test.ts test/report-session-relay.test.ts test/bridge-final-output-retry.test.ts test/trigger-session-turn-idempotency.test.ts test/trigger-session-root-message.test.ts test/session-store.test.ts test/daemon-codex-app-workflow-wiring.test.ts
# 7 files, 507 passed

bun run test test/daemon-rename-route.test.ts test/cli-adapters.test.ts test/plugin-cli-generation.test.ts test/prompt-hook-injection.test.ts test/bot-config-store.test.ts test/reply-delivery.test.ts test/trigger-session-reply-mode.test.ts
# 7 files, 754 passed, 1 skipped

bun run test test/doc-comment-prompt.test.ts test/trigger-session-idempotency-e2e.test.ts test/skill-injection-mode.test.ts test/initial-user-turn-opening.test.ts test/cli-session-selection-prompt.test.ts test/worker-argv-reaction-status.integration.test.ts test/credential-boundary-prompt.test.ts test/initial-prompt-arg-limit.test.ts test/command-trigger-reserved-commands.test.ts test/available-bots-collapse.test.ts test/prompt-builder.test.ts test/codex-app-clean-prompt.test.ts test/card-integration.test.ts test/trigger-session-root-message.test.ts test/prompt-hook-injection.test.ts test/trigger-session-turn-idempotency.test.ts test/session-adopt.test.ts test/role-resolver.test.ts test/session-skill-injection.test.ts test/command-handler.test.ts test/api-only-mode-wiring.test.ts test/scheduler-silent-execute.test.ts test/card-handler-repo-select.test.ts test/card-handler-stop-compact.test.ts test/card-handler-retry-turn.test.ts test/bridge-input.test.ts test/command-retry.test.ts
# 27 files, 1071 passed（共享输入构建调用方）

bun run test test/customization-api.test.ts test/dashboard-customization-ui.test.ts
# 2 files, 18 passed

bun test test/daemon-codex-app-workflow-wiring.test.ts
# 4 passed

bun run build
# 通过，含脚本/测试 mock 类型检查及构建产物审计

git diff --check
# 通过

行为验证包括：模拟 lead 接受请求后 HTTP 响应丢失，重试仅产生一次 worker 输入；回报失败时子会话仍完成结算；开关两个方向、旧会话恢复与 fork；全部 10 个 CLI 的首轮、续轮、refork 仅保留任务及附件；选仓首轮与后续轮附件分别保存，没有重复拼接。

使用隔离配置在浏览器验证多选、批量设置、名称展示及搜索；真实名册 55 个 bot 均能解析名称。已执行 bun run switch:here && bun run daemon:restart 部署测试；最新部署后 56 个服务在线，近期日志未发现错误。直接群 @ 实测创建了冻结为 none 的新群会话，CLI 首轮输入中未出现 Botmux 信封、提醒或自动附加的 report/send 完成指令；该轮完整最终回复仍在观察中。尚未将各 CLI 的单元测试视为原生端到端验证。

页面示意（中性测试数据）：

[deepcoldy]

自动评审初步意见（最终以维护者审阅为准）。基于最新 master（merge-base 79e75b1）阅读完整 diff，并本地复跑：bun run build 0 错；PR 相关 18 个测试文件 1279 passed / 1 skipped，相邻 dispatch/transcript 回归 14 文件 342 passed；对四处关键新逻辑（输入短路、配置拒写、claude 参数提前返回、final 自动回报 hook）做了变异验证，对应新用例全部如期变红。

整体设计扎实：能力判定复用「最终回复可自动采集」白名单而非另维护一份名单；配置写入侧与 worker 生成侧双闸 fail-closed；共享技能目录「拒启不删文件」的处理克制；剥除派单完成协议前先验 HMAC 绑定、且只按精确构造串剥离，用户正文不受影响。以下两条建议合入前确认。

P2-1 自动回报在重试下不是 at-most-once，且修法不是单点改动

onZeroPromptFinal 在 worker-pool.ts 的 deliverFinalOutput 中被 await，位于 Lark 投递成功之后、lastBridgeEmittedUuid / markTurnReplyDelivered 之前。它一旦抛错（如 lead daemon 短暂离线，findOnlineDaemon 返回 null），catch 会重跑整个 final 投递体；而回报经 buildOrchestratorReportTrigger 发出的 /api/trigger 不带任何幂等选项。若回报 HTTP 已被 lead 受理但响应丢失，重试会让 lead 再吃一个 turn。

两处实现约束供修改时参考：

1. options.turnIdempotencyKey 被 validator 限定在「既有会话的 async 追加」场景（trigger-types.ts 校验：必须同时有 target.sessionId 与 options.asyncReturnSessionId: true，且不能配 wait/dryRun），只加 key 会被 400 拒绝。好在 request hash 覆盖 source，而 source.requestId 已经是确定性的 zero-prompt:<sessionId>:<turnId>（daemon.ts），同 key 重试可以正确收敛到已有 turn。
2. 建议同时把「回报 lead」与「本子会话最终回复投 Lark」解耦为独立 best-effort：回报失败只记日志/标记，不驱动 final_output 的重试。否则 lead 瞬态离线会把 sub 自己的完成态卡在重试中（卡片因 uuid 幂等不重发，但 dedupe 标记与 idle 结算被跳过，重启后还可能重投）。

并建议补一条测试：同一 (sessionId, turnId) 的回报重试只产生一个 lead turn。

P2-2 绑定话题内每一轮 final 都会回报 lead

deliverFinalOutput 对每个 bridge final 都触发回报，多轮 sub 会话（修一改二）会按 N sub × M 轮向 lead 注入整合 turn。projectUpdate: {} 保证不污染项目状态，但 lead 的消耗被放大。请明确这是预期语义，还是需要加收敛（安静期 / 仅末轮 / 由 lead 侧去重）。

P3（不阻断，记录备查）

• 输入侧（zeroPromptInjectionForBot、effectiveReplyDelivery）读的是实时 bot 配置，worker spawn 与回报判据读的是会话冻结值（cfg.promptInjection / ds.initConfig）。字段标注 effect=next-session，但输入剥壳对存活会话立即生效，两个方向都有外显的混合态：运行中 default→none 时派单协议被剥但自动回报不触发（结果回不到 lead）；none→default 时正文重新带上 report 指令而冻结的自动回报仍在（lead 可能双收）。建议输入侧也读会话冻结值，或在切换时明确提示需重启会话。
• 零注入正文仍含编排框架文本：post 往返后首行的角色后缀（如 （Worker）；当 at 未进入 mentions 时整行 @name（role） 保留）与尾部「分工：」脚注不在剥除范围内。任务正文本身干净，这些是残留框架信息。
• /adopt 的 init 消息不带 promptInjection/replyDelivery，零注入 bot adopt 外部会话时静默回退为全注入（安全方向，无错误承诺，但没有任何提示）。
• stripDispatchCompletionProtocol 只构造 LF 候选，CRLF 形态会安全地保留后缀；当前唯一携带通道经富文本解析归一化为 LF，实际不可达，记录于此。
• adopt 活 pane 热重接（willReattachPersistent）跳过插件生成闸，共享目录断言不执行；同一 turn 若出现多个不同终态 final 会各回报一次（受转写桥单终态语义约束，罕见）。

另：PR 描述中对 --into 未绑定消息根时完成协议无法去除的已知缺口披露充分，代码两侧（剥除与回报）行为一致地依赖绑定存在，核实无误。