feat: 聊天历史和用户消息注入时间戳

[lishuceo]

Summary

• 飞书消息的 create_time 时间戳之前在 parseMessage 中被丢弃，Claude 完全不知道当前时间
• 现在将时间信息注入到 user prompt 侧（非 system prompt），避免 cache miss
• 历史消息格式：[HH:MM] [姓名]: 内容（跨天显示日期，跨年显示完整日期）
• 当前消息末尾附带 <msg-time> 元数据标签

改动文件

• src/feishu/client.ts — fetchRecentMessages 返回 createTime
• src/feishu/event-handler.ts — formatCreateTime 函数 + 历史消息时间前缀 + 当前消息时间元数据
• src/session/queue.ts + types.ts — QueueTask 传递 createTime
• src/__tests__/message-time.test.ts — formatCreateTime 单元测试

Test plan

• formatCreateTime 单元测试：同一天、跨天、跨年、UTC+8 边界（6 cases）
• 已有 history-truncation 测试通过（12 cases）
• queue 测试通过（19 cases）
• 全量 vitest run 通过（973/974，1 个 pre-existing flaky failure）

🤖 Generated with Claude Code

[claude]

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

---

PR Review: feat: 聊天历史和用户消息注入时间戳

• Check for previous review comments — none found
• Read changed files and understand context
• Review code for bugs, security, architecture issues
• Post review summary

---

✅ Approved

Clean, well-scoped PR. The timestamp injection approach is sound — adding time to the user prompt side rather than system prompt avoids cache misses while giving Claude temporal awareness.

What I reviewed:

• formatCreateTime — Manual UTC+8 offset is correct (China doesn't observe DST). Edge cases handled well: undefined, empty string, '0', NaN all return undefined. Date component comparisons using UTC methods after offset are correct.
• Data pipeline — createTime flows cleanly through parseMessage → handleMessageEvent → taskQueue.enqueue → processQueue → executeClaudeTask/executeDirectTask. No dropped or misrouted values.
• History formatting — Time prefix [HH:MM] role: text is clean and informative. Graceful degradation when createTime is absent (no prefix, same as before).
• <msg-time> tag — Injected at the end of user prompt, non-intrusive metadata pattern.
• Tests — 6 test cases cover same-day, zero-padding, cross-day, cross-year, and UTC+8 boundary scenarios. Good use of vi.useFakeTimers().
• Type changes — QueueTask.createTime and ParsedMessage.createTime are properly optional, backwards-compatible.

Minor observations (not blocking, confidence < 75):

• The enqueue() method now has 9 positional parameters. An options object pattern would improve readability, but that's a pre-existing issue this PR merely inherits — not a reason to block.
• The _testFormatCreateTime export pattern works fine for unit testing private functions.

No bugs, security issues, or architectural concerns found.