fix(lark): 修复仓库选择卡吞卡、恢复与搜索

[47seek]

问题

真实环境扫描 132–134 个项目时，首次仓库选择卡会间歇性发送失败，表现为 socket hang up / write EPIPE；更严重的是同步扫描期间第一次 @机器人 约 1 分钟没有任何可见反馈，容易被误认为消息被吞。

现场剖析一次 134 项扫描：

• 总耗时 76,170 ms；
• 245 次 Git 子进程占 75,946 ms；
• stat / readdir 仅约 0.2 秒；
• 主要热点是 detached Flow worktree 逐个执行 git describe --tags --exact-match HEAD，仓库约有 117,370 个 tag，单次可耗 2–6 秒；
• 同步扫描阻塞 daemon 事件循环，扫描后第一笔卡片请求可能复用已被服务端关闭的 keep-alive socket。

改动

首次 @ 不再等待扫描

• 保持原同步 scanner 的扫描结果、排序、去重、worktree 和 tag 识别语义不变，仅放到隔离 child process 执行。
• pending session 注册完成后立即回复“正在扫描仓库，您的消息已暂存”，随后释放 per-anchor serializer；扫描期间同话题的 follow-up、/repo、/close 可正常处理。
• child 完成后再发原仓库卡；如果 route 已被 /repo、关闭或其它入口消费，丢弃迟到结果并回收迟到卡，不会二次 fork。
• 扫描结果为空时复用 pending commit 事务，将扫描期间的补充消息、附件、mentions、sender、chat context 和最新 turn id 一次性折入唯一首轮 fork。
• child 异常时保留 pending input，并给出 /repo 文本恢复入口。

卡片超限、陈旧连接与失败恢复

• 首次仓库卡使用稳定的 repo-picker:<sessionId> provider UUID。
• 仅对 EPIPE、ECONNRESET、ECONNABORTED、ETIMEDOUT、socket hang up 等瞬时传输错误自动重发一次，首发与重发共用 UUID，避免重复卡。
• wire bytes 预算按最终 request data 计算并控制在 12,000 bytes 内。
• 两次发送都失败才保留 /repo <name|path> 文本兜底；route 已消费或正在 commit 时不再发过时恢复文案。
• 仓库卡保留搜索框，可从完整 lastRepoScan 按项目名、分支或路径搜索；搜索结果保持原始完整列表编号。
• 搜索和单/多仓库模式切换继续使用“新卡发送成功后再回收旧卡”及 session/card-id CAS，失败时不吞活动卡。

行为说明

• 扫描仍可能因大仓库 tag 数量耗时，但不会再阻塞 daemon，也不会让第一次 @ 静默。
• 原卡片与仓库选择流程保留；不会靠“下一张卡回收上一张再重发”来掩盖失败。
• 卡片暂不可用时，用户仍可立即回复 /repo <项目名|路径>，或 /repo 使用当前工作目录；首轮消息和扫描期间补充均不会丢。

验证

• 聚焦回归：7 files、492 tests passed
  • child scanner 与同步结果严格相等
  • parent event loop 保持响应
  • 生产形态 anchor serializer 在扫描期间释放
  • follow-up 缓冲、bare /repo 接管、empty scan 单次 fork
  • route replacement、迟到结果/卡片撤回、card delivery 竞态、child failure 恢复
  • 卡片裁剪、搜索、原始编号、稳定 UUID 与连接重试
• 全量单测：816 files passed，13,091 tests passed，36 skipped
• pnpm exec tsc --noEmit
• pnpm build
  • domain audit、TypeScript、dashboard bundle、dist audit 全部通过
  • runtime build id: 4ac0b8dd7335
• 编译产物 child IPC smoke 通过。
• git diff --check
• 两轮独立只读复审无 blocking correctness 问题。

现场验证

部署 3191bd3a 后，在新话题第一次 @机器人：

1. 应立即看到扫描中提示；
2. daemon 在扫描期间仍能接收 follow-up 或 /repo；
3. 扫描结束后显示选择卡，或空结果时自动开始；
4. 不再需要第二次 @ 才唤醒首轮消息。

扫描卡交接补充（e2caa193）

• 第一次 @ 后立即发送独立、不可操作的“正在扫描仓库”卡片。
• 扫描完成时先发送完整仓库选择卡，成功后撤回扫描卡；正常情况下话题里只保留最终选择卡。
• 未直接 PATCH 原卡：现有仓库选择卡包含 Lark v1 form，PATCH 会出现空卡；因此保留原搜索、手工路径和多 worktree 表单逻辑。
• 扫描卡使用独立稳定 UUID，瞬时传输失败原 UUID 重试；route 被 /repo、/close 或其它入口消费时会回收迟到卡。
• 修复旧扫描卡发送失败清空新选择卡授权 ID 的竞态。

验证：聚焦回归 8 files / 513 tests passed；TypeScript、build、diff check 通过。全量 819 files 中 815 passed、3 skipped，1 个无关 worker 状态集成测试在并行负载下超时；该文件随后隔离重跑 3/3 passed。runtime build id: 170f86b9ddaf。

[47seek]

已追加首次 @ 扫描无反馈的修复并部署验证环境：

• latest head: 3191bd3a（已 rebase 最新 master）
• 同步 scanner 语义不变，改为 child process 执行；pending 注册后立即发扫描中提示并释放 anchor serializer
• follow-up、bare /repo、route replacement、迟到卡、empty scan 单次 fork、child failure 都有路由回归
• 聚焦：492/492 passed
• 全量：13,091 passed / 36 skipped
• TypeScript、build、compiled child IPC smoke、diff-check 均通过
• runtime build id: 4ac0b8dd7335
• 4 个 bot daemon 已重启到该构建并保持 online；未合并，等待 CI 与 review。

[deepcoldy]

与 #797 的合并协调说明

#797（给同步扫描加进程内预算护栏 maxScanDirs/maxScanMs + onBudgetExceeded 提示卡，定位为纵深防御/缓解）已双审通过，将先行合并作为快速止血。

本 PR（#756）是同一问题的根治向修法（把扫描 fork 进子进程 + watchdog 超时），层次更深、体量更大，继续按自身节奏收敛即可。

需要注意的一处冲突：#797 合入后，本 PR 会在 src/core/command-handler.ts 的 /repo 处理块与 i18n 键上产生文本冲突——#797 把该块改成了「同步 scanMultipleProjects(..., { onBudgetExceeded })」，本 PR 是「await scanMultipleProjectsAsync(...)」。

建议的解法：保留本 PR 的异步子进程扫描，同时把 #797 的 onBudgetExceeded 部分结果提示语义接过来——因为子进程内部仍调用同一个同步 scanProjects，#797 的预算护栏在子进程里依然生效，两层叠加（预算让单次扫描有界 + watchdog 兜底内核挂死）是最稳的组合。i18n 只需保留双方各自新增的键（scan_budget_no_repos/scan_budget_partial 与本 PR 的 list_limited/refresh_failed/repo_card_unavailable 等）即可，互不冲突。