feat(lark): 支持 oncall 回复审核后公开 #1360

背景

在 oncall 群里使用 botmux 时，agent 可能会产出大段中间分析、噪声日志摘要、未确认推断或错误结论。如果这些内容直接发到群里，会影响求助用户和旁观成员的体验，也可能让值班人来不及先校正表达或过滤不该公开的信息。

希望 botmux 支持一种按 bot 开启的「回复审核发布」能力：agent 的最终回复先只对值班人/审核人可见，确认无误后再公开到原群或原话题。

User Story

作为 oncall 值班人，我希望 botmux bot 在完成排查后不要立即把最终回复公开给用户，而是先把回复以仅我可见的审核卡片发给我。确认内容正确、表达合适且不包含敏感信息后，我可以点击「公开到群里」让用户看到最终答复；如果结论错误或需要继续追问，我可以点击「丢弃」，群里不留下这条错误答复。

典型流程：

1. 用户在 oncall 群里描述问题并 @ 对应 bot。
2. botmux 启动或复用会话，agent 完成排查并产出最终回复。
3. 最终回复不会立即公开，而是先以「仅特定人可见」审核卡发送给本轮值班人或配置指定的审核人。
4. 值班人确认回复正确后点击「公开到群里」，群成员才看到最终答复。
5. 如果值班人认为结论错误、内容过长或包含敏感信息，可以点击「丢弃」，再追问 agent 或人工回复。

需求范围

• 能力必须按 bot 单独开启。一个 oncall bot 开启后，不影响其它协作 bot 的默认公开回复体验。
• 配置入口建议放在 Dashboard 的「消息卡片 -> 任务卡片」区域，和任务执行状态卡片、手动私有快照等卡片行为放在同一上下文里。
• 第一版只控制最终回复，不强行覆盖运行过程中的流式状态卡、思考过程消息、终端快照等过程输出。
• 如果用户需要 oncall 群里完全不展示中间过程，应同时关闭「任务执行时显示状态卡片」。

建议配置

建议新增 bot 维度配置：

{
  "privateReplyReview": {
    "enabled": false,
    "audience": "requester",
    "fallback": "dm",
    "expireHours": 24
  }
}

字段建议：

Dashboard 入口：

Bot Defaults -> 消息卡片 -> 任务卡片 -> 最终回复审核发布

实现建议

飞书开放平台已有「发送仅特定人可见的消息卡片」能力：

• POST /open-apis/ephemeral/v1/send
• POST /open-apis/ephemeral/v1/delete

botmux 仓库里也已有 sendEphemeralCard / deleteEphemeralCard 封装。这里建议采用两阶段发布，而不是尝试把 ephemeral 卡片原地变成公开消息：

1. 最终回复先作为仅特定人可见的审核卡发送给审核人。
2. 审核卡里包含「公开到群里」和「丢弃」按钮。
3. 审核人点击公开后，botmux 使用普通 sendMessage / replyMessage 在原落点重新发送一条全员可见消息。
4. 公开成功或丢弃后 best-effort 删除 ephemeral 卡片。
5. 使用稳定 uuid 和本地 publish record 保证重复点击、长连接重投和 daemon 重启恢复不会重复公开。

需要接入的发送路径：

• 显式 botmux send。
• daemon 从 worker final_output 兜底转成的最终回复。

不建议第一版接入：

• doc comment / HTTP virtual / apiOnly。
• VC meeting managed delivery。
• 过程流式卡片或思考过程消息。

验收标准

• 配置关闭时，所有 bot 保持现有直接公开回复行为。
• 仅开启该配置的 bot 进入审核发布流程，其它 bot 不受影响。
• 普通群中，审核人能看到「仅对你可见」审核卡，其他群成员看不到最终回复正文。
• 审核人点击「公开到群里」后，群里出现一条全员可见最终回复。
• 话题群中，审核卡可通过 DM 发送给审核人；公开后回复落回原话题。
• 点击「丢弃」后，群里不出现这条回复。
• 重复点击公开不会产生重复消息。
• 非审核受众即使拿到 callback payload，也不能公开。
• 如果运行过程卡片仍开启，配置文案需要明确提示过程信息仍可能在群里可见。

本地设计文档

本地已补充设计草案：docs/design/2026-09-08-private-reply-review.md。