feat(card): 新增 persistentStreamCard 配置支持会话内复用同一张流式卡片

[yujiaze]

背景

默认每轮对话都「发新流式卡 + 撤回旧卡」，长会话反复重发/撤回体验较吵。

改动

新增 per-bot 全局配置 persistentStreamCard：开启后一个会话只在首轮 POST 一张卡，
后续每轮用 updateMessage 原地 PATCH 同一张卡（标题跟随最新一轮）。与
disableStreamingCard 互斥（后者优先），默认关闭、行为不变。

实现要点

• daemon.ts beginNewTurn：持久模式且已有存活卡片时，跳过冻结旧卡、不置
  streamCardPending，使下轮 screen_update 天然命中 worker-pool 既有复用 PATCH 分支
  （restoredCardId = streamCardId && !streamCardPending），首轮无卡仍 POST 一次。
• 刻意不动 re-fork / relay / repo 切换路径（显式清 streamCardId，无法可靠复用）。

影响面

集中在飞书卡片编排层，不碰 im/lark 事件路由，与 CLI / 后端无关；话题群/普通群/
私聊同走 beginNewTurn 一致生效；默认关闭时行为完全一致。

验证

• tsc 全量编译通过；dashboard 前端 bundle 成功
• 直接相关单测 91/91、邻近单测 550/550 通过
• 全量 unit 另有若干 pre-existing 失败（session-discovery / v3-distillation-runner /
  vc-meeting 等，与本改动无关，stash 对比干净基线同样失败）

[deepcoldy]

这里有一个会绕过 persistentStreamCard 的后续 turn 路径，建议在 ready 前修掉并补回归测试：

src/im/lark/card-handler.ts 的 retry_last_task 仍无条件执行 ds.streamCardPending = true。该分支会先 scheduleCardPatch 更新当前卡，但后续任一 screen_update 会因为 pending=true 进入 worker-pool 的 POST 分支，发新卡并 recall 旧卡。因此开启 persistentStreamCard 后，用户从限额卡点击“重试上次任务”仍会出现本 PR 想消除的“发新卡 + 撤旧卡”。现有 test/card-integration.test.ts 还固定断言 retry 后 pending=true，说明当前测试没有覆盖新开关语义。

建议：

• retry 路径与 beginNewTurn 共用同一“本 turn 是否复用已有卡”判断（至少在 persistent + real card + live worker 时保持 pending=false）；
• 新增核心状态机回归：默认模式第二轮仍 POST；persistent 模式第二轮只 PATCH 同一 message id；retry_last_task 在 persistent 模式也只 PATCH；首轮、re-fork/relay 等刻意例外保持原行为；
• PR 描述说“一个会话每个后续 turn 都复用”，但实现刻意排除了 re-fork/relay/repo switch，文档最好同步说明这些例外。

本地验证：pnpm build 通过；相关 6 个测试文件 325/325 通过，但本 PR 没新增测试覆盖上述分支。全量 unit 为 9861/9865，3 个时区失败可在 PR parent 复现，另 1 个 v3-host 并发用例单跑即通过，均与本改动无关。

[deepcoldy]

感觉是不是用dashboard中的关闭流式卡片功能就行了，需要的时候/card召唤卡片？

[deepcoldy]

感谢这个方案！我们重新对照了一下现有能力：如果核心诉求是减少群里的状态卡噪音，Dashboard 中的「关闭飞书流式卡片」配合 /card 按需召唤，似乎已经能覆盖——关闭后最终答案仍会照常作为新消息送达，/card 可以临时召唤当前 turn 的实时卡，下一 turn 会自动回到关闭状态；如果只想对单个群关闭，也可以用 /card off，之后用 /card on 恢复。

这和本 PR 的 persistentStreamCard 是两个方向：前者是“默认不出卡，需要时召唤”，后者是“始终自动出卡，但整个会话复用同一张”。想请作者帮忙补充一下实际使用场景：现有按需方案具体有哪些不满足，为什么仍需要自动常驻同一张卡？如果确实有独立需求，我们再基于场景继续评估，并处理前面提到的 retry 分支和回归测试；如果没有，可能暂时不增加这个配置会更简单。谢谢！