fix: 修复 Codex base_url 被写入错误 TOML section

[makoMakoGo]

Fixes #1441

用户视角的问题描述

用户在新增 Codex BYOK / 自定义供应商时，填写的 API 请求地址看起来已经保存成功，但实际写入 config.toml 后，base_url 可能被追加到文件最后一个 TOML section，而不是当前供应商对应的 [model_providers.<name>] 下。

从用户角度看，现象就是：

• 新增渠道后界面没有明显报错
• 配置文件里能看到 base_url
• 但 Codex 实际无法按预期识别这个渠道，新增渠道不可用

这个问题在配置里已经存在 Codex common config、并且 common config 会生成额外 section 时尤其容易触发，因为此时“追加到文件末尾”不再等价于“写入当前 provider section”。

说明：这个 PR 处理的是 Codex BYOK / 自定义渠道的 config.toml 写入问题，不涉及官方 OAuth 登录令牌本身的生成或刷新逻辑。

变更说明

• 让 Codex base_url 的读取和写入都基于当前 model_provider 做 section-aware 处理
• 将 base_url 写入 [model_providers.<当前供应商>]，不再简单追加到文件末尾
• 当配置里只有一条被错误写到其他 section 的 base_url 时，保存时会将其迁回当前供应商 section
• 将 Codex 相关的几个读取入口统一复用共享 helper，避免继续各自手写正则
• 补充回归测试，覆盖 [model_providers.custom] 后面还有其他 section 的场景

测试

• corepack pnpm vitest run tests\utils\providerConfigUtils.codex.test.ts tests\hooks\useCommonConfigSave.test.tsx tests\components\CommonConfigModalBehavior.test.tsx tests\components\AddProviderDialog.test.tsx
• corepack pnpm tsc --noEmit
• cargo test in src-tauri on commit db42dfc8: passed (488 unit tests in src/lib.rs plus all Rust integration tests, 0 failed)

风险与验证建议

• 对于正常由 cc-switch 生成的 Codex BYOK 配置，这次修改应当符合预期；如果本地 config.toml 曾被手工修改，或者已经残留了被旧逻辑写到错误 section 的 base_url，建议额外 spot check 一次
• 建议在 macOS / Windows 上实际验证：开启 Codex common config 后新增 BYOK provider、填写 Base URL、保存并切换，确认 config.toml 中的 base_url 落在正确的 [model_providers.<name>] section 内

[makoMakoGo]

还有点问题，我再思考下🤔

[makoMakoGo]

codex config.toml 配置写入这块似乎因为 toml 格式自身的缘故 有点 难搞，通用配置 写回这块 也没 claude 那块优雅，claude的可以去重，codex这块还存在重复问题，以及只能追加到最后的问题，不知道作者有没有想到一个绝妙的点子处理。

[farion1231]

被 toml 折磨了很久了，我研究一下

[makoMakoGo]

看到作者已经修了，就关闭了 🤗

[farion1231]

看到作者已经修了，就关闭了 🤗

在后端彻底重构了一下，感谢您的贡献！