fix: insights 替换策略可能导致有效信息丢失

[uchouT]

当前 insights 采用替换策略（设计决策 #3）：每次 integration 整体覆盖子 Session 的 insight 槽位。这把「保留仍然有效的旧信息」的负担完全放在了 IntegrateFn 上。

风险场景

第一次 integration 推送的 insight:
  "学生预算上限 50 万 RMB，注意筛选学费"
  "学生看重就业，建议补充 OPT/H1B 数据"

第二次 integration 推送的 insight:
  "学生改为考虑 Oxford，竞争更激烈"
  （IntegrateFn 未重复提及预算信息）

→ "预算 50 万"从子 Session 上下文中消失

如果 IntegrateFn 的 prompt 写得不够周全，有效信息会静默丢失。

可能的改进方向

• 将历史 insight 作为 IntegrateFn 的参考输入，降低遗漏风险
• insights 改为 append-only，由框架保留历史
• 或其他机制，待讨论

Refs #35

[uchouT]

进一步思考，我还是更加认可当前的做法, insight 是一个一次性寄存器：

1. integrate 写入 → 覆盖旧值
2. send 读取并注入上下文 (L3) → 清除
3. 下次 integrate 再写入新值

insights 是 main session integration 的产物, 始终和当下最新状态绑定, 对于上面的风险场景，预期的表现是:

第一次 integration 推送的 insight:
  "学生预算上限 50 万 RMB，注意筛选学费"
  "学生看重就业，建议补充 OPT/H1B 数据"

第二次 integration 推送的 insight:
( 如果上一个 insights 推送的问题没有被解决并更新 L2 )
  "学生预算上限 50 万 RMB，注意筛选学费"
  "学生看重就业，建议补充 OPT/H1B 数据"
  "学生改为考虑 Oxford，竞争更激烈"
  （IntegrateFn 还是应该注意到这些问题, 并推送）

并且, 对于这样的 "学生预算上限 50 万 RMB，注意筛选学费" 这种全局性的知识, 更好的做法是通过 shared memory / system prompt 机制, 而不是每次都由 integrateFn 检查。目前框架没有原生提供, 作为框架使用者可以在实现存储接口时手动拼装，或者利用现有的 systemPrompt 接口。

不同 session 间感知的延迟是一次 integration.

append only 会导致 insights 膨胀, 如果每次 integration 符合预期, 那么旧的 insights 就是干扰项。

@Difficult-Burger cc @Ec3o

[Ec3o]

我觉得 insights 更像是上层到下层的偏提醒作用的单次推送消息，用来补充子session不知道的全局上下文的作用