chore: add diagnostic logging for history dedup pipeline

[lishuceo]

Summary

• 在 fetchRecentMessages 中添加诊断日志：API 返回条数、类型过滤跳过原因（deleted / unsupported_type / parse_error / empty_content）、最终解析的消息 ID 和类型列表
• 在 buildDirectTaskHistory 中添加诊断日志：afterMsgId 值、currentMessageId 过滤前后计数、dedup 过滤前后计数、最终消息 ID 列表
• 在 executeDirectTask 中添加诊断日志：afterMsgId 来源（conversationId + _historyDedup 状态）、history 结果概要

目的

追踪 pm-bot 在群聊中无法看到紧挨着的 merge_forward 消息的根因。当前日志只有 promptLength 无法定位消息在哪个环节被丢弃。

日志级别

全部使用 logger.debug，不影响正常日志输出。需要时通过 LOG_LEVEL=debug 或在 .env 中临时启用。

Test plan

• 合并部署后，在群聊中转发一条聊天记录，然后引用回复 @土豆儿
• 检查 debug 日志，确认 merge_forward 在哪个环节被过滤

🤖 Generated with Claude Code

[claude]

Claude finished @lishuceo's task in 54s —— View job

---

PR #140 Review: Diagnostic logging for history dedup pipeline

• Check for previous review comments — none found
• Read changed files in full context
• Review diff for issues
• Post review summary

---

✅ Approved

Clean diagnostic logging PR. All changes are logger.debug, no runtime behavior changes, no sensitive data leakage (only IDs, types, and content lengths — not actual message content).

Minor observation (confidence ~60, not filing inline):
The foundIdx field at event-handler.ts:1858 is named like an index but emits 'found'/'not_found' strings. The inference logic (messages.length !== beforeDedupFilter) works correctly in all cases, but renaming to something like afterMsgIdMatch would be slightly clearer. Not blocking.

Summary: Well-scoped diagnostic change that should help trace the merge_forward filtering issue. No bugs, no security concerns, no architectural issues.