fix: 重启通知发到话题内而非群主聊天

[lishuceo]

Summary

• 服务重启后的中断通知现在会发送到用户原来的话题内，而不是群主聊天
• 同时修复了 workspace restart query 缺少 threadId/threadRootMessageId 的问题

根因

1. shutdown 保存中断 session 时（src/index.ts），只保存了 chatId，没有保存 threadRootMessageId
2. restart 通知时，用 sendText(chatId, ...) 直接发到群主聊天，而不是话题
3. workspace restart query（src/feishu/event-handler.ts）缺少 threadId 和 threadRootMessageId 参数

修复

1. shutdown 时从 session 中读取 threadRootMessageId 一并保存到中断文件
2. restart 后优先用 replyTextInThread() 发到话题，无 threadRootMessageId 才 fallback 到主聊天
3. workspace restart query 补上 threadId 和 threadRootMessageId
4. 新增 SessionManager.getByKey() 方法支持直接按 key 查询 session

Test plan

• 在话题中发消息触发任务，手动重启服务，确认通知发到话题内
• 在主聊天发消息触发任务，重启后通知仍然正常发到主聊天（fallback）
• workspace 切换后的 restart query 能正确回复到话题

🤖 Generated with Claude Code

[claude]

Claude finished @lishuceo's task in 1m 29s —— View job

---

PR Review: fix: 重启通知发到话题内而非群主聊天

• Check for previous review comments — none found
• Read changed files and full source context
• Trace function calls across module boundaries
• Post review findings

---

✅ Approved — Clean, well-targeted fix. No issues found.

Assessment

The three changes work together correctly:

1. src/session/manager.ts — getByKey() is a clean passthrough to the DB, consistent with existing patterns. Appropriate for the shutdown path which already has the raw key.

2. src/index.ts (shutdown) — Correctly reads threadRootMessageId from the session before saving to the interrupted file. The session DB is still open at this point (closed later in shutdown sequence), so this is safe.

3. src/index.ts (restart notification) — Dedup logic s.threadRootMessageId ?? s.chatId correctly handles all cases:

   • Two sessions in the same thread → deduplied, one notification to the thread
   • Thread session + main chat session → both get notified (thread + main chat)
   • No threadRootMessageId → falls back to sendText(chatId) (existing behavior preserved)

4. src/feishu/event-handler.ts — threadId and threadReplyMsgId are both in scope (function parameters of executeClaudeTask), and the executor interface accepts these optional fields. This ensures the workspace restart query can correctly associate with the thread for session tracking.

No bugs, no security issues, no resource leaks. The fallback behavior preserves backward compatibility.

---