现象
在飞书群聊（group chat）中转发一条消息给 bot 时，飞书会把这个动作拆成两条独立的消息事件：被转发的原消息卡片 + 用户补充的文字。botmux 会把「引用消息」和「补充信息」开成两个独立会话（session），而不是合并进同一个会话。
定位
读了下 dist 源码，合并能力其实是存在的（ForwardFollowupBuffer 的 hold/take，用补充消息的 root_id 去配对转发卡片的 message_id），配对键设计是正确的。但有两处门控把它关住了：
- 合并被门控在
usesForwardFollowupDelay 下，只在 regularGroupMentionMode ∈ {never, ambient} 时生效（im/lark/event-dispatcher.js）；而默认值是 always（services/chat-reply-mode-store.js 的 resolveGroupMentionMode），即默认关闭。
- 更关键：即便切到
never/ambient，shouldDelayTopicSeed（im/lark/event-dispatcher.js，约 3160 行）还额外要求 routingSource === 'topic-chat' —— 也就是 seed-hold 合并只对话题群（topic chat）开了口子，普通群（regular group）完全没接这条路径。
结果：普通群里转发卡片以 anchor = message_id① 建会话 A，补充文字（带 root_id 但无 thread_id，被当成顶层消息）以 anchor = message_id② 建会话 B；sessionKey = anchor::appId 两者不同 → 两个独立会话，永不配对。
问题
- 普通群不支持「转发卡片 + 补充文字」合并，是有意的设计取舍，还是待补的能力？
- 是否有计划让普通群也走 seed-hold 合并（放宽
topic-chat 限制 / 给普通群单独接一条配对逻辑）？
- 还是官方定位就是「此合并能力仅面向话题群」？
环境：botmux v3.16.1
现象
在飞书群聊（group chat）中转发一条消息给 bot 时，飞书会把这个动作拆成两条独立的消息事件：被转发的原消息卡片 + 用户补充的文字。botmux 会把「引用消息」和「补充信息」开成两个独立会话（session），而不是合并进同一个会话。
定位
读了下 dist 源码，合并能力其实是存在的（
ForwardFollowupBuffer的 hold/take，用补充消息的root_id去配对转发卡片的message_id），配对键设计是正确的。但有两处门控把它关住了：usesForwardFollowupDelay下，只在regularGroupMentionMode ∈ {never, ambient}时生效（im/lark/event-dispatcher.js）；而默认值是always（services/chat-reply-mode-store.js的resolveGroupMentionMode），即默认关闭。never/ambient，shouldDelayTopicSeed（im/lark/event-dispatcher.js，约 3160 行）还额外要求routingSource === 'topic-chat'—— 也就是 seed-hold 合并只对话题群（topic chat）开了口子，普通群（regular group）完全没接这条路径。结果：普通群里转发卡片以
anchor = message_id①建会话 A，补充文字（带root_id但无thread_id，被当成顶层消息）以anchor = message_id②建会话 B；sessionKey = anchor::appId两者不同 → 两个独立会话，永不配对。问题
topic-chat限制 / 给普通群单独接一条配对逻辑）？环境：botmux v3.16.1