fix(catalog): honor Manager context window for suffixless custom models (#1594)

[LeoLin990405]

Root cause

apply_model_catalog_to_config returns before generating a catalog when a custom model has neither a [window] suffix nor bundled metadata — even if the user configured a context window in the Manager. The parse_optional_positive_u64(&profile.context_window, …) that reads the user's value sat after that early return, so it never ran. Codex then falls back to its bundled 272000 default (→ 272000 − 13840 reserved ≈ 258160, the "258K" users report) regardless of the 1M they set.

Repro (from #1594): custom provider on http://127.0.0.1:57321/v1, model deepseek-v4-flash (native 1M), Manager context window = 1,000,000 → Codex CLI shows 258K / 258K for every model.

Fix

Parse the configured window first, then generate the catalog whenever there is anything to customize — a [window] suffix, bundled metadata, or a user-supplied context window. When the user set no window, behavior is unchanged (a plain custom model still gets no generated catalog).

let fallback = parse_optional_positive_u64(&profile.context_window, "上下文大小")?;
if fallback.is_none()
    && !entries.iter().any(|entry| {
        entry.suffix_window.is_some()
            || crate::model_suffix::requires_bundled_metadata_catalog(&entry.slug)
    })
{
    return Ok(config_text.to_string());
}

Verification

New regression test generates_catalog_with_user_context_window_for_suffixless_custom_model (RED before the fix, GREEN after). cargo test -p codex-plus-core --lib → 202 passed, 0 failed.

Fixes #1594.

[BigPizzaV3]

审查结论：当前分支仍不能合并。Windows artifacts CI 的 relay_config 有两个失败：apply_relay_profile_does_not_write_model_catalog_json_for_selected_models 与 apply_relay_profile_no_catalog_when_model_list_has_no_suffix 仍断言不生成 catalog，但现行实现已在配置 context window 时生成 catalog。请同步 #1786 或更新这两个旧断言后重新跑 CI。

[LeoLin990405]

已折入那两个集成测试的修复(commit 3060250),CI 应转绿。

apply_relay_profile_{does_not_write_model_catalog_json_for_selected_models, no_catalog_when_model_list_has_no_suffix} 之前给 profile 设了 context_window 却断言"不生成 catalog"。修复后配置窗口会生成 catalog,所以把这两个无后缀用例里的窗口去掉,让它们继续测"无后缀/无内置元数据/无配置窗口 → 无 catalog"这条路径;window→config.toml 的写入在 line ~1207 的用例仍有覆盖,window→catalog 的新行为由 generates_catalog_with_user_context_window_for_suffixless_custom_model 覆盖。

本地 cargo test -p codex-plus-core --test relay_config → 105 passed / 0 failed。

感谢 @dongyu23 在 #1786 里定位到这两个集成测试 —— 已在本 PR 内一并修好,保持单一 PR 自洽。

[LeoLin990405]

已 rebase 到最新 main 并重新应用修复。之前 Windows CI 唯一的 red 是 tests/upstream_theme_assets.rs(bundled_*_remain_byte_exact)——本 PR 只改 relay_config.rs、未碰任何 assets/,该失败源于分支 base 落后 53 个提交带来的陈旧资产状态,与本改动无关。rebase 到当前 main 后本地全套绿(cargo test -p codex-plus-core 所有测试二进制 0 failed,含 upstream_theme_assets 与 relay_config)。核心修复与两处集成测试更新不变。

[BigPizzaV3]

复审确认核心修复成立：当前 main 仍在解析 profile 级 context_window 前提前返回，导致无 [window] 后缀、无内置 metadata 的自定义模型不生成 catalog；把 fallback 解析前移并增加该回归测试能修复 #1594。现在唯一阻塞是分支与最新 main 冲突。请 rebase 最新主线、保留这组最小改动并重新跑 relay_config 与三平台 CI，之后可以继续合并评估。

[BigPizzaV3]

核心修复结论不变：无后缀且无内置 metadata 的自定义模型，应在配置了 context_window 时生成 catalog。请 rebase 当前 main（已包含 #1934 和后续 relay_config 迁移），保留最小改动并重新运行 relay_config、core 与三平台 CI；冲突解决且 CI 转绿后可继续合并评估。

[BigPizzaV3]

main 已更新到 7385664。请 rebase 后保留最小 catalog 修复：无后缀、无内置 metadata 的自定义模型仅在显式配置 context_window 时生成 catalog；同时补未配置窗口不改变旧行为的回归测试并跑三平台 CI。

[LeoLin990405]

已按 review rebase 到最新 main(冲突解决:保留 official_deepseek_responses && starts_with("deepseek-v4-") 分支,叠加 fallback.is_none() 守卫),并补上未配置窗口不改变旧行为的回归测试 no_catalog_for_suffixless_custom_model_without_context_window(无后缀、非内置、非 deepseek-v4 的自定义模型在未配置 context_window 时不生成 catalog)。

最小改动保持:仅在显式配置 context_window 时,为无后缀/无内置 metadata 的自定义模型生成 catalog。本地 cargo test -p codex-plus-core 全部测试二进制 0 failed(含 relay_config、upstream_theme_assets 与三平台通用测试),等三平台 CI。

[LeoLin990405]

补充定位:本 PR 的 Windows artifacts red 不来自本 PR 的改动,而是 main 自身的 Windows 编译回归。

• 失败是编译错误 error[E0599]: no method named 'into_owned' found for struct 'std::string::String',位置 crates/codex-plus-core/src/dream_skin.rs:593(以及一处 grok_config.rs)。该函数是 #[cfg(windows)] 的 normalized_identity_string,raw 由 path.to_string_lossy().replace('/', "\\") 得到,已是 String,String 无 into_owned()。非 Windows 平台不编译该函数,所以 macOS DMG 两个 job 均绿、本地 cargo test 全绿。
• main 自己的 "PR build artifacts" 在 7385664(green)之后已连续失败:080611c5 → failure、当前 2fa2a6c → failure。本 PR rebase 到 2fa2a6c 便继承了这个与本改动无关的 Windows 编译错误。

一行修复(供参考):dream_skin.rs:593 的 .unwrap_or_else(|| raw.into_owned()) 改为 .unwrap_or_else(|| raw)(raw 已是拥有所有权的 String)。

本 PR 的改动本身已按 review 就绪:最小 catalog 修复 + 两个方向的回归测试(generates_catalog_with_user_context_window_* 与 no_catalog_for_suffixless_custom_model_without_context_window)+ 两个集成测试更新,macOS/本地全绿。main 的 Windows 编译修好后可重跑三平台 CI。

[LeoLin990405]

已把导致本 PR Windows red 的 main 编译回归单独修了:#2024(dream_skin.rs 的 #[cfg(windows)] 路径归一化里 raw.into_owned() 应为 raw,已用 rustc --target x86_64-pc-windows-msvc 交叉验证)。#2024 合入 main 后,本 PR rebase 重跑三平台 CI 即可全绿。本 PR 自身改动(macOS 双绿 + 本地全套绿)不受影响。