feat: 扩展按模型上下文管理，支持自动压缩与模型元数据导入

[dongyu23]

背景

现有版本已经支持按模型配置上下文窗口。本次 PR 在此基础上继续扩展按模型的配置能力，使不同模型可以拥有更符合自身特性的上下文、自动压缩和能力元数据。

我近期观察到 DeepSeek 已开始原生适配 Responses API。随着 Responses API 被更多第三方模型提供商采用，模型之间在推理档位、工具能力、截断策略、响应格式和多模态支持方面的差异会越来越明显。继续让所有第三方模型沿用同一套默认能力配置，会限制实际使用效果，也会让用户难以根据模型特性进行调整。

目前 Codex 内置模型目录主要由 GPT/Codex 系列模型组成。对于内置目录中没有匹配到的第三方模型，原有回退逻辑会借用首个内置模型的字段结构和部分能力默认值。因此，未知模型可能继承与自身实际能力不一致的 GPT 模型配置，例如默认推理档位、verbosity、工具类型、截断策略和并行工具调用能力。

本 PR 继续沿用现有上下文管理和 model_catalog_json 机制，为第三方 Responses 模型提供更具扩展性的配置方式。

功能预览

管理器会根据当前模型名称匹配 models.json 中相同 slug 的条目，并同步上下文窗口、自动压缩阈值和模型能力元数据。

主要改动

按模型配置自动压缩

• 为每个模型增加自动压缩百分比配置
• 支持整数和小数百分比，例如 90%、84.5%
• 根据当前模型的 context_window 自动计算 auto_compact_token_limit
• 未填写时继续使用 Codex 默认的 90% 行为
• 对上下文窗口和自动压缩值进行前后端一致校验

导入模型元数据

• 在每个模型配置行提供 models.json 导入入口
• 支持完整的 models.json、模型对象数组和单个模型对象
• 支持常见的 export default 和 module.exports JSON 包装
• 不执行任意 JavaScript，只解析 JSON 内容
• 根据当前模型输入框中的名称，从文档的 models 数组中自动匹配同名 slug
• 多模型文件只导入当前模型对应的条目
• 找不到匹配模型时显示文档中可用的模型名称
• 检测到重复 slug 时拒绝导入，避免覆盖错误配置

导入内容除了上下文窗口和自动压缩阈值，还可以包含模型自身的能力字段，例如推理档位、verbosity、截断策略、并行工具调用、图片输入和供应商扩展字段。

模型名称同步

• 修改模型名称并失去焦点时，会同步迁移该模型已经导入的元数据
• 支持连续修改多个模型名称
• 删除模型时只清理该模型不再使用的元数据
• 保存前清理已经不在模型列表中的历史元数据
• 处理重复模型名称解除后的链式改名，避免元数据错配

配置边界与默认值

• context_window、auto_compact_token_limit 等由 Codex++ 管理的字段不会作为普通元数据覆盖
• max_context_window、priority、visibility、supported_in_api 等托管字段会被明确提示为未导入
• 每模型窗口仍由模型列表配置生成，避免外部元数据覆盖用户明确设置的窗口
• 对未知第三方模型使用更中性的能力默认值，并允许通过模型元数据显式覆盖
• 如果外部 catalog 与按模型配置同时存在且发生冲突，保存和应用阶段会直接报错，不再静默忽略用户设置

用户界面优化

• 更新供应商总览中的上下文窗口说明
• 全局上下文窗口留空时不写入全局值
• 填写全局值时，将其作为该供应商所有模型的上限，并继续受 catalog 中 max_context_window 约束
• 使用逐模型窗口时，引导用户留空全局上下文值
• 在导入工作台中显示当前匹配的模型名称
• 导入后显示实际被忽略的 Codex++ 托管字段
• 补充新增后端错误的英文翻译

兼容性

• 保留已有的 profile 级上下文窗口配置
• 保留原有 model_list 和 model_windows 配置格式
• 不启用逐模型自动压缩和元数据时，沿用原有行为
• 纯官方登录 profile 不会在普通启动时被强制应用第三方 relay 配置
• API 模式下启动时会刷新对应的 catalog
• catalog 刷新失败会记录警告，但不会阻塞 Codex 本体启动
• 保存和切换配置时使用事务性校验，失败时不会留下半更新状态

验证

本地已完成：

• npm test，74 项测试通过
• npm run check
• npm run vite:build
• git diff --check
• Fork CI 全平台构建运行 31511989597，Windows、macOS Intel 和 Apple Silicon 全部通过

本机当前没有 Rust 工具链，Rust 和跨平台打包由上述 CI 完成验证：

• cargo test --workspace
• Rust release build
• Windows 构建产物
• macOS Intel DMG
• macOS Apple Silicon DMG

关联

本 PR 是 #1197 合并后对按模型上下文管理能力的后续扩展。

#931 记录了第三方模型上下文窗口未按配置生效的运行时问题。本 PR 继续沿用 Codex 原生 model_catalog_json 机制，并扩展自动压缩和模型元数据配置。

[dongyu23]

Fork CI using the same .github/workflows/pr-build.yml passed for commit e4bf126. Windows artifacts, cargo test --workspace, macOS x64 DMG, and macOS arm64 DMG all passed.

The upstream pull_request workflow is currently action_required and needs maintainer approval before it can run.

[dongyu23]

Rebased onto upstream/main at 1f431ae and resolved the provider-save/model-route conflicts while preserving the per-model context metadata behavior.

Latest head: beeac69

Fork CI passed on the rebased head:

• Windows frontend tests, TypeScript check, cargo test --workspace, release binaries, and NSIS installer
• macOS x64 release build and DMG
• macOS arm64 release build and DMG

Fork CI run: https://github.com/dongyu23/CodexPlusPlus/actions/runs/31802597533

[BigPizzaV3]

按模型自动压缩和元数据导入本身有价值，但这个分支当前不能按整体合并。

相对最新 main，它已经是约 3654 行新增、384 行删除，除了目标功能还改动 launcher、Computer Use Guard、诊断日志、供应商应用/清理事务和大量旧 UI。主线在此后已经独立调整或移除了其中若干行为，直接解决冲突很容易把旧逻辑重新带回，且无法判断回归来自自动压缩、元数据导入还是无关同步代码。

请基于最新 main 重做并拆分：

• 第一部分只保留 modelAutoCompact、catalog 计算、前端编辑与对应测试；
• 第二部分再单独提交模型元数据导入、受保护字段和外部 catalog 冲突处理；
• 不要携带 launcher、Computer Use Guard、诊断日志等与该功能无关的旧基线改动。

每个 PR 都应保持 opt-in，并分别覆盖旧 profile 无新字段时生成内容不变、每模型窗口与压缩阈值计算、外部 catalog 冲突失败不留半更新文件。当前分支已与 main 冲突，旧分支不建议继续直接合并。