Preserve rollout mtimes during sync

[zlsq]

摘要

• 在重写 rollout provider 元数据时保留文件修改时间
• CLI 路径下避免使用 rename 方式覆盖 rollout 文件，改为原地回写
• rollout 重写成功后恢复原始 mtime
• 补充 JS 和 .NET 测试，覆盖“保留修改时间”的行为

背景

当前 codex-provider sync 在同步 provider 时，会重写 ~/.codex/sessions 和 ~/.codex/archived_sessions
下的 rollout 文件。

虽然 provider 同步本身是正确的，但这个过程会刷新文件时间。对于依赖 rollout 文件时间做启动扫描或活跃会话判断
的工具来说，这会带来副作用：历史会话可能会被误判成“刚刚活跃过的会话”。

我这边实际遇到的现象是：

• 执行 codex-provider sync 后
• 某些会读取 ~/.codex/sessions 的工具会把大量历史 Codex session 误加载出来
• 根因不是 provider 同步逻辑错误，而是 rollout 文件时间被整体刷新了

修改内容

CLI / Node 实现

• 保持现有 provider 同步逻辑不变
• 在非 Windows 路径下，不再通过 rename 覆盖 rollout 文件
• 改为原地写回文件内容
• 写回成功后恢复原始 mtime
• Windows 的 rewrite / restore 路径也补上 mtime 恢复

Desktop / .NET 实现

• rollout 重写成功后恢复原始 LastWriteTimeUtc
• 不改变现有同步、备份、SQLite 更新逻辑

验证

• npm test

说明

这次改动是一个尽量小的修复，只处理 rollout 文件重写带来的时间戳副作用，不改变以下行为：

• provider 解析逻辑
• backup 行为
• SQLite 同步语义

[Dailin521]

Thanks for the patch. The .NET side looks fine, but there is still one blocking issue on the JS path.

Blocking:

• In src/session-files.js, restoreFileMtime() reads snapshot.mtimeMs, but the Windows applySessionChanges() path passes the collected change object, which only has originalMtimeMs. That means the mtime restore becomes a no-op on Windows for the main sync path.
• I pulled this branch locally and re-ran npm test; the new test runSync preserves rollout modified time after rewriting provider metadata fails for exactly this reason.

Please fix the field mismatch on the JS side and re-run the test suite. After that this PR should be in much better shape.

改为使用中文 review，结论不变。

[Dailin521]

感谢提交。.NET 这边看起来没问题，但 JS 路径目前还有一个阻塞点。

阻塞问题：

• src/session-files.js 里的 restoreFileMtime() 读取的是 snapshot.mtimeMs，但 Windows 下 applySessionChanges() 传进去的是收集阶段的 change 对象，这个对象只有 originalMtimeMs，没有 mtimeMs。结果就是主同步路径下的 mtime 恢复在 Windows 上实际没有生效。
• 我已经把这个分支拉到本地重新跑过 npm test，新增的 runSync preserves rollout modified time after rewriting provider metadata 用例会直接失败，问题和这里一致。

建议先修正 JS 侧字段不一致的问题，并重新跑完整测试；这个点修完后，这个 PR 会更接近可合并状态。