问题
飞书卡片消息已成功发送（日志显示"发送卡片成功"），但手机端一直显示"思考中"，AI 响应永远不更新。
根因：飞书卡片展示流式内容依赖 OpenCode 的 SSE 事件流。当事件流断开后，sendMessagePartsAsync 发起的请求虽然成功，但后续的流式输出数据无法通过断开的连接到达 bridge，卡片永远无法更新。
修复逻辑（两层防护）
第一层：发送前主动检查事件流健康（src/opencode/client.ts + src/handlers/group.ts）
在 GroupHandler.processPrompt 发送异步消息之前，调用 ensureEventStreamActive()：
如果事件流是活的 → 直接继续
如果事件流断了 → 主动重置并重连，重连成功再发送消息
这样从源头确保流式输出的通路是通的。
第二层：卡死检测兜底（src/lifecycle/buffer-callback.ts）
万一事件流重连也失败了（或者有其他未知原因导致输出卡死），60 秒无新内容自动将 buffer 标记为 failed，触发卡片更新为"失败"状态，避免用户永远看到"思考中"。
问题
飞书卡片消息已成功发送（日志显示"发送卡片成功"），但手机端一直显示"思考中"，AI 响应永远不更新。
根因：飞书卡片展示流式内容依赖 OpenCode 的 SSE 事件流。当事件流断开后，sendMessagePartsAsync 发起的请求虽然成功，但后续的流式输出数据无法通过断开的连接到达 bridge，卡片永远无法更新。
修复逻辑（两层防护）
第一层：发送前主动检查事件流健康（src/opencode/client.ts + src/handlers/group.ts）
在 GroupHandler.processPrompt 发送异步消息之前，调用 ensureEventStreamActive()：
如果事件流是活的 → 直接继续
如果事件流断了 → 主动重置并重连，重连成功再发送消息
这样从源头确保流式输出的通路是通的。
第二层：卡死检测兜底（src/lifecycle/buffer-callback.ts）
万一事件流重连也失败了（或者有其他未知原因导致输出卡死），60 秒无新内容自动将 buffer 标记为 failed，触发卡片更新为"失败"状态，避免用户永远看到"思考中"。