perf: short-circuit model list via bridge (−34s startup)

[lennney]

Summary

Intercept list-models-for-host calls in the renderer inject script and return model names from the Codex++ bridge (<1ms) instead of waiting for the app-server RPC (~34s).

Inspired by PR #620 by @congxb.

How it works

1. Bridge is already loaded and has the model catalog
2. When codex calls list-models-for-host, intercept and check bridge
3. If models are available, return immediately via patchAppServerModelResult — skip the full app-server roundtrip
4. If models not yet loaded, load them on-demand then short-circuit
5. If bridge is disabled or models unavailable, fall through to original RPC

Verification

• Model list still works correctly (bridge falls through to original RPC if models not loaded)
• 91 tests passing (1 pre-existing failure — also on upstream/main)

[Copilot]

Pull request overview

该 PR 在 Codex 渲染器的注入脚本中拦截 list-models-for-host 请求：当 Codex++ bridge 已能提供模型目录时，直接用 bridge 的模型名构造返回值，从而跳过首次启动时耗时很长的 app-server RPC 往返（PR 描述中约 34s），以显著降低启动阶段模型列表可用的等待时间。

Changes:

• 在 client.sendRequest 的补丁中对 list-models-for-host 增加短路逻辑：优先从 /codex-model-catalog 加载/读取模型名并立即返回
• 当 bridge 模型名不可用时保持原行为：回退到原始 sendRequest（app-server RPC）

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[BigPizzaV3]

想确认一下这个优化的基准：原始 list-models-for-host 请求在你的测试环境里是稳定很慢吗？

能否补一下测量方式/日志，例如：

• 触发场景（启动时、打开模型选择器、供应商切换后？）
• 原请求平均/最慢耗时，以及是否每次都接近 34s
• 慢在 app-server 本地处理、账号/host 判断，还是上游网络请求

另外短路后模型列表完全依赖 Codex++ catalog。这里是否验证过官方账号模式下不会丢掉 app-server 实时返回的模型差异？如果 bridge catalog 为空会 fallback 原请求，这点我看到了；主要想确认 catalog 非空但过旧/不完整时的行为。