feat(codex): 更新 Cindy 内置 Codex Runtime，并明确与系统 CLI 的独立更新机制

## 使用场景 / Use case

希望在 Cindy 中使用较新的、经过 Cindy 验证的 Codex Runtime，并能够清楚区分：

1. Cindy 自己管理的内置 Codex Runtime 版本；
2. 用户在系统终端中单独安装的 Codex CLI 版本；
3. OpenAI 当前已发布的稳定版本。

我在 Windows x64 上使用 Cindy `0.1.66`。排查版本差异时发现：

- Cindy「设置 → 关于」显示 Codex `0.145.0`；
- 系统终端中的 `@openai/codex` 已经是 `0.151.0`；
- Cindy 实际调用的是自己管理的 `%APPDATA%\CindyGlobal\codex\0.145.0\codex.exe`，而不是系统 `PATH` 中的 npm CLI；
- 当前仓库主分支的 [`tools/codex/latest.json`](https://github.com/makecindy/cindy/blob/main/tools/codex/latest.json) 也仍固定为 `0.145.0`。

因此这不是客户端未重启或 npm 更新失败，而是 Cindy 的 vendored Codex Runtime 仍然锁定在 `0.145.0`。

## 当前问题 / Current limitation

目前 OpenAI Codex CLI 的稳定版本已经推进到 `0.151.0`，但 Cindy 内置 Runtime 仍为 `0.145.0`。普通用户容易误以为：

- 更新 Cindy 应用后，内置 Codex 也会同步更新；
- 在终端执行 `npm install -g @openai/codex@latest` 后，Cindy 会使用该版本；
- 「关于」页面显示旧版可能只是缓存或探测失败。

实际排查后才知道，Cindy 使用的是一套独立下载、校验和版本锁定的 Runtime。这个设计本身是可以理解的：Cindy 需要控制兼容性、启动参数、协议变化、SHA-256 校验以及跨平台回归，不一定适合无条件追随上游最新版。

不过，长期停留在较旧版本也会让用户错过后续版本中的会话管理、导出、任务管理、MCP、权限恢复、模型切换、Windows 沙箱和多 Agent 等修复与改进。旧 Runtime 还可能扩大 Cindy 与上游 Codex 行为之间的差异，增加问题排查成本。

仓库中已经有几个相关记录：

- #1604：希望 Codex 新版发布后及时推送并显示更新提示；
- #1367：建议升级 vendored Codex 至 `0.147+`；
- #2722：记录 Cindy 内置 Codex `0.145.0` 在部分第三方模型工具调用中的兼容问题。

这次提交主要是补充当前时间点的实际情况：Cindy 已更新至 `0.1.66`，上游稳定版已到 `0.151.0`，但 Cindy 主分支和本地运行时仍为 `0.145.0`。

## 期望方案 / Proposed solution

非常理解 Runtime 升级需要兼容性验证，不要求 Cindy 在上游每次发布后立即无条件跟进。希望团队可以考虑：

1. **将 Cindy 内置 Codex Runtime 从 `0.145.0` 更新到 `0.151.0`，或更新到团队确认兼容的较新稳定版本。**
2. 升级时继续保留 Cindy 现有的版本固定、下载校验和回滚机制。
3. 在「设置 → 关于」中明确标注“Cindy 管理的 Codex Runtime”，避免与系统全局 Codex CLI 混淆。
4. 如果检测到上游已有新版但 Cindy 尚未跟进，可以显示：
- Cindy 当前内置版本；
- 上游最新稳定版本；
- 当前状态，例如“兼容性验证中”或“等待随 Cindy 更新发布”。
5. 如果存在固定的 Runtime 更新节奏或版本选择原则，希望能在文档或界面中简单说明。
6. 建议升级回归至少覆盖：
- Windows x64 启动、下载与 SHA-256 校验；
- 新建、恢复、分叉和归档会话；
- 权限模式、沙箱和工作目录切换；
- MCP、插件和 Skills；
- 多 Agent / 子代理；
- 官方 Codex 路线及 Cindy 支持的主要第三方 Provider。

如果 `0.151.0` 因接口或协议变更暂时不适合直接升级，也希望维护者能说明目前计划采用的目标版本，或者在相关 Issue 中同步一下进度。清晰的预期本身就能减少用户误判和重复排查。

感谢团队持续高频更新 Cindy。这个建议不是要求简单覆盖内部二进制，而是希望在保持兼容性和稳定性的前提下，让内置 Codex Runtime 的版本跟进和状态说明更加明确。

## 已考虑的替代方案 / Alternatives considered

### 手动替换 Cindy 内部的 `codex.exe`

没有采用。Cindy 使用版本目录和 `.verified` 标记管理 Runtime，直接替换可能绕过兼容性验证，并可能在后续启动或更新时被覆盖。

### 只更新系统全局 Codex CLI

已经尝试并成功更新到 `0.151.0`，但 Cindy 不读取系统 `PATH` 中的 npm CLI，因此不会改变 Cindy 内部 Runtime。

### 让 Cindy 始终直接使用系统 CLI

不一定适合作为默认方案，因为不同用户可能通过 npm、Homebrew、winget 或独立安装器安装不同版本，可能破坏 Cindy 的可复现性和兼容性保障。继续由 Cindy 管理 Runtime 是合理的，只希望其版本升级和状态提示更加及时、透明。

---

**环境信息**

- Cindy：`0.1.66`
- OS：Windows x64
- 界面语言：zh-CN
- Cindy 内置 Codex Runtime：`0.145.0`
- 系统全局 Codex CLI：`0.151.0`

Start with tools/codex/latest.json and trace how Cindy downloads, verifies, selects, and displays the bundled Codex Runtime. Confirm the target version and update cadence with maintainers before changing version metadata or UI wording. Done means the selected Runtime and status are clear, existing verification and rollback behavior remain intact, and the listed Windows and session-related regressions are checked.

Written by the indexing model from the issue text.