[Bug][Codex Helper] 长时间运行时磁盘写入量异常偏高且缺少文件级归因

## 现象

macOS 修正根 PID 后的第 3–5 个采集窗口合计约 41 分钟。相关进程累计写入 766.746 MiB，其中 Helper（codex app-server）写入 750.613 MiB，占 97.9%；若速率持续，约为 1.1 GiB/小时。三个窗口均出现约 12 MiB/s 的相近写入峰值。测试数据没有操作标记和文件路径。

## 复现步骤

1. 在 macOS 上以正确的 Cindy 根 PID 启动进程树性能采集。
2. 正常使用包含 Codex app-server 的 Cindy 会话，连续运行至少 40 分钟。
3. 保留多个连续采集窗口，记录 Helper、Main、Renderer、Agent 的累计读写量。
4. 对比各模块写入占比，并记录 Helper 的平均写速和峰值写速。
5. 继续静置 Cindy，观察 Helper 是否仍持续写入。
6. 使用文件级跟踪定位实际写入的文件、调用路径和触发操作。

## 期望行为

Helper 的磁盘写入应与明确业务数据对应，空闲后回到基线；日志、transcript、数据库或缓存不应产生无法解释的持续写放大，并应能定位写入来源。

## 实际行为

第 3–5 个窗口中 Helper 写入 750.613 MiB，占相关写入 97.9%，约合 1.1 GiB/小时；当前采集无法确认具体文件和触发操作。

## 源码分析

采集器把主要写入归类到 Helper（codex app-server）。Cindy 同时存在 SQLite WAL、消息持久化、Agent transcript/日志及会话状态路径，但现有数据没有文件级跟踪，不能把写入归因给其中任何一项。需要先补齐 PID、文件路径和操作打点，再确定写放大的具体实现位置。

## 验收标准

- [ ] 对 Helper 写入增加 PID、文件路径、字节数和触发阶段的可追踪数据。
- [ ] 固定场景重复至少 3 次并执行 2 小时 soak，确认写入来源和增长曲线。
- [ ] 空闲稳定窗口内 Helper 写入速率回到可解释基线。
- [ ] 消除无法解释的持续写入或写放大，同时保留必要日志、会话恢复和 transcript 能力。
- [ ] 分别验证启用/停用 Worker、日志、embedding 和持久化路径的对照组。
- [ ] 完成 macOS 与 Windows 共用链路回归。

Start by tracing the existing performance collector and Helper attribution path; the issue names no specific files or tests. Add PID, file path, byte count, and trigger-stage data, then repeat the three-run, two-hour soak with Worker, logging, embedding, and persistence comparisons. Done means the write source and growth curve are explained, idle writes return to baseline, and macOS and Windows regressions pass.

Written by the indexing model from the issue text.