[s08] 建议：将 compact_history 与 reactive_compact 合并为一个函数

s08 现在有两条压缩入口：compact_history()（prepare() 超阈值时、以及 compact 工具触发）和 reactive_compact()（API 报 prompt_too_long 时触发）。文档把它们讲成「预防」和「补救」两个概念很清晰。但代码逻辑，我觉得没有很好的体现补救的价值。

首先，两个触发点面对的 messages 其实完全相同——prepare() 返回之后紧接着就是 API 调用，中间没有任何修改 messages 的代码。输入相同、目标相同，却写了两套逻辑。

建议是文档继续讲两个概念，代码收敛成一个 compact(messages, active_request, keep_tail, label)，两条路径变成不同参数：预防用 keep_tail=3, label="Compacted"，补救用 keep_tail=0, label="Reactive compact"。

Locate compact_history(), reactive_compact(), prepare(), and the compact tool entry point, then trace how each path handles the same messages before the API call. Consolidate the shared behavior while preserving the stated keep_tail and label differences, and verify that both preventive threshold compaction and prompt_too_long recovery still work.