feat(context/runtime): 落地 manual compact（拆分自 #127）并补齐配置、TUI、事件与测试

[wynxing]

变更背景

这是从 #127 拆出来的 manual-only 版本,但也是我最终决定只修改的版本，去掉micro compact

原 PR 同时包含了 micro compact 和 manual compact 两部分能力，反馈是一次性改动过大。这个拆分版本只保留手动 compact 主链路，移除 micro 自动压缩相关实现，方便单独评审和合入。

本 PR 保留的内容

1. Manual compact 核心能力

• 新增 internal/context/compact，提供 manual compact runner
• 支持 keep_recent / full_replace 两种手动策略
• compact 前先落盘 transcript（JSONL）
• 生成并校验 compact_summary
• 字符统计与 summary 截断统一按 rune 语义处理

2. Runtime 接入

• 新增 runtime.Compact(...) 手动入口
• 保留 compact_start / compact_done / compact_error 事件
• compact 成功后回写 session
• compact 失败时正确返回错误并派发事件
• Run 与 Compact 串行化，避免并发写同一会话

3. 配置与 TUI

• 新增 context.compact.* 配置：
  • manual_strategy
  • manual_keep_recent_spans
  • max_summary_chars
• TUI 接入 /compact
• 支持 compact 进行中状态与重入拦截
• 补充空会话下 /compact 的本地拦截，避免暴露底层 session_id is empty

4. 其他修复

• discoverRuleFilesWithFinder 遇到目录读取错误时显式返回错误，不再静默吞掉

5. 文档同步

• README 增加 manual compact 说明
• docs/guides/configuration.md 增加 compact 配置与 /compact 说明
• docs/runtime-provider-event-flow.md 补充 manual compact 事件流

本 PR 明确不包含

• 不包含 micro compact
• 不包含自动在每轮 provider 请求前执行 compact
• 不包含 micro_enabled、tool_result_keep_recent、tool_result_placeholder_min_chars
• 不包含 micro_compact_applied 事件
• 不迁移 my-changes.patch

测试与验证

本地已通过：

go test ./internal/context/...
go test ./internal/runtime
go test ./internal/tui
go test ./internal/config
go test ./...

close #120

[codecov]

Codecov Report

❌ Patch coverage is 80.67416% with 172 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/context/compact/runner.go	79.20%	35 Missing and 28 partials ⚠️
internal/runtime/compact.go	66.00%	24 Missing and 10 partials ⚠️
internal/tui/update.go	82.87%	20 Missing and 11 partials ⚠️
internal/runtime/runtime.go	79.38%	12 Missing and 8 partials ⚠️
internal/runtime/compact_generator.go	71.42%	6 Missing and 6 partials ⚠️
internal/config/model.go	82.22%	4 Missing and 4 partials ⚠️
internal/context/compact_prompt.go	95.74%	1 Missing and 1 partial ⚠️
internal/context/source_rules.go	80.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[minorcell]

@Yumiue

我这边主要有几点建议：

第一，尽量不要直接修改其他人负责的模块。因为你未必完全了解那部分代码的设计背景和后续计划，贸然改动容易引入不符合预期的实现，甚至会让对应 owner 在后续继续开发时，还要额外花时间理解和接手你新增的代码。

第二，既然架构上已经做了职责拆分，就应该尽量遵守这个边界。你把自己负责模块内的能力实现好、接口提供出来即可，其他模块如何接入，应当由对应负责人自己来完成。否则会越过模块边界，也容易让协作上显得比较冒犯。

第三，从 PR 组织的角度看，也建议控制改动范围，尽量保持“小步快跑”。这次你在实现自己模块功能的同时，又修改了其他模块，导致整个 PR 变得比较大，reviewer 阅读和评审都会比较吃力，也不容易判断这些跨模块改动应该和谁讨论、由谁来确认。

以这个 PR 为例，你在 context 里把 compact 功能和接口提供出来就已经足够了；后续只需要通知 @pionxe 和 @creatang，让他们分别去完成 runtime 和 tui 侧的修改即可，不建议在这个 PR 里继续直接改那两部分代码。