话题群里带时间窗的 +chat-messages-list 会静默漏掉话题回复（only_thread_root_messages=true 被硬编码）

问题现象

im +chat-messages-list 固定发送 only_thread_root_messages=true（#635 引入，动机是"与 topic-group 用法保持一致"）。在话题群（chat_mode=topic）里，这会让 --start/--end 按话题根消息（thread root）的
create_time 过滤，而不是按每条消息自身的时间——于是一条发在查询窗口内、但所在话题的 root 早于窗口的回复，会被整体排除。结果是：群里明明在活跃讨论，带时间窗的查询却返回 messages: []。

这对本 CLI 的主要使用者（做增量读取的 AI agent）非常危险：空结果会被解读成"这段时间没有任何新消息"，而真相是"这种查询形态看不到它"。目前 CLI 侧没有任何办法关掉这个参数——它硬编码在
buildChatMessageListParams（shortcuts/im/im_chat_messages_list.go）里。

复现步骤

1. 在话题群 oc_xxx 里开一个话题，放几天不动。
2. 今天在这个话题里发一条回复。
3. lark-cli im +chat-messages-list --chat-id oc_xxx --start <今天> --end <明天> --as user
   → 今天这条回复不见了（常见返回 total: 0）。

用 raw 调用（lark-cli api GET /open-apis/im/v1/messages，同一个群、同一个时间窗、只改这一个参数）做过对照：

传 false 时，服务端把 root 和话题回复作为一个平铺列表返回，按每条消息自身的 create_time 过滤、且遵循 sort_type 排序（实测 ByCreateTimeAsc 下严格升序，root 与回复交织；回复带
parent_id/root_id）。

诉求

1. 提供一个可选开关——例如给 +chat-messages-list 加 --include-thread-replies，置位时发送
   only_thread_root_messages=false（默认行为不变），并保留现有的富化能力（正文解码、发送人姓名、message_app_link）。
2. 无论最终怎么改，请在 skills/lark-im/SKILL.md / 命令参考文档里把这个坑写清楚：话题群里带时间窗查询返回空，不代表这段时间没人说话。 Agent 是逐字照着这份文档执行的。
3. only_thread_root_messages 在公开的「获取会话历史消息」文档里没有记载，但 CLI 目前已经无条件依赖它——能否确认这个参数（尤其是 =false）会长期支持？

Start in shortcuts/im/im_chat_messages_list.go at buildChatMessageListParams, then inspect the command's option wiring and existing tests, if any. Check skills/lark-im/SKILL.md and command reference documentation; done means an opt-in thread-reply mode preserves existing enrichment, defaults remain unchanged, and the time-window caveat is documented.