fix: prioritize redundant read outputs before unique history #58

为什么

v6 只按时间清理旧工具输出。当最早的一份独有结果之后有多次相同读取时，引擎先丢弃独有信息，重复信息却继续占用预算。这与减少冗余、保留有效证据的目标相反。

范围与做法

• 在现有成功工具输出候选规则之内，对 read/grep/glob 的相同工具名、完整序列化输入和逐字相同输出识别重复，优先折叠旧副本。
• 只在原有超预算或手动 force 入口运行；保留近期完整步骤、单项收益门槛及所有现有保护。
• 最新可见副本在重复清理阶段保留；仍超预算时继续现有从旧到新的有损折叠，并明确不保证永久保留每类结果。
• 不从同一路径推断修改覆盖关系；不删除消息、输入、错误、推理或工具配对，不修改存储历史和原生摘要。
• 输出不含正文的重复清理计数，更新中英文用户文档和设计审查记录，按四个设计方向记录能力缺口及可验证的后续方案。

验收

• 构造一次折叠即可满足预算的场景，证明旧版折叠唯一结果而新版保留唯一结果、清理后面的重复旧副本。
• 不同分页、同输入不同输出、已有 compacted 标记、失败/运行中工具、指令、并行近期工具均不被错误识别或绕过保护。
• 原始消息深度不变；投影唯一变化为符合条件的 compacted 标记；已有调用 ID、输入与输出仍完整存在。
• 真实宿主加载、数据库读取、插件 dispatch、provider wire 序列化验证最新副本和唯一结果可见，调用配对和数据库不变。
• 格式、类型、单测、打包、最低/最新 SDK 兼容矩阵、固定宿主和 SpecGit 验收通过。

补充硬约束与默认值

• 压缩不拥有 Agent 状态机，不能 pause、abort、等待 idle 后停工压缩、触发 summarize 或重启执行。失败保留原始请求，原宿主继续；用户显式取消仍由宿主正常处理。
• 新增真实公开宿主连续工具场景，在默认策略下先命中重复清理，再执行慢工具、自然进入原生压缩并继续后续工具，逐条检查成功退出和副作用只发生一次。AI SDK 与 Native LLM 两种模式均验收。
• 用户不手动调参。重复优先默认启用；选择并保留近期至少4步且16000估算tokens、预算比例0.7、单项最低收益512的已验证默认值。运行时、schema、中英文说明一致；不覆盖用户已有配置。