model-provider: route model discovery through HTTP client factory

[bolinfest]

Why

Model discovery is a startup-critical request path, but /models still constructed a default reqwest client directly. As a result, features.respect_system_proxy could cover Responses traffic while model catalog refreshes bypassed the same OS proxy policy.

The proxy policy must come from the Config for the operation that actually triggers model discovery. Thread start and resume can apply configuration overrides, so capturing an HttpClientFactory when the process-wide models manager is constructed is not sufficient.

What changed

• Require an HttpClientFactory on model-manager operations that may fetch the remote catalog, and propagate the current request/session config through every call site.
• Construct the exact /models?client_version=... URL once and use it both to resolve the outbound route and to execute the request.
• Resolve synchronous PAC/WinHTTP APIs on Tokio's blocking pool, with a bounded client-build permit and single-flight cache misses.
• Include proxy resolution and the HTTP request in the existing five-second models refresh timeout.
• Keep static model catalogs functionally unchanged; they accept the mandatory factory but do not perform network I/O.
• Add focused tests for request-time policy propagation, exact-URL transport selection, and the single-flight resolver invariant.

Review guide

1. models-manager/src/manager.rs makes the factory a request-time dependency and forwards it to ModelsEndpointClient.
2. model-provider/src/models_endpoint.rs builds the exact models URL, selects the route-aware transport, and applies one timeout to resolution plus request execution.
3. login/src/auth/default_client.rs moves the synchronous client build off the async runtime; http-client/src/outbound_proxy.rs makes cache misses single-flight.
4. The core, app-server, and CLI edits are mechanical propagation from the Config that owns each operation.

Validation

• cargo check --tests -p codex-http-client -p codex-login -p codex-api -p codex-models-manager -p codex-model-provider -p codex-core -p codex-app-server
• just test -p codex-http-client -p codex-api -p codex-models-manager -p codex-model-provider
• just test -p codex-app-server models_refresh_worker

Follow-up

Other direct reqwest consumers are migrated in the subsequent PRs in this stack.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• login: route raw auth flows through HTTP client #31637
• build: ratchet direct reqwest dependencies #31431
• codex-api: route file uploads through HTTP client factory #31363
• core: route realtime and memories through HTTP client factory #31362
• -> model-provider: route model discovery through HTTP client factory #31361

[viyatb-oai]

One cancellation-safety issue remains in the bounded PAC client build.

[viyatb-oai]

Can we move the permit into the blocking closure? The outer five-second timeout cancels this future and drops _permit, but Tokio keeps an already-started spawn_blocking task running. A later refresh can then acquire the permit and enqueue another PAC/WinHTTP lookup, so repeated timeouts defeat the intended bound.

Suggested change

	let _permit = ROUTE_AWARE_CLIENT_BUILD_PERMIT
	.acquire()
	.await
	.map_err(std::io::Error::other)?;
	tokio::task::spawn_blocking(move || {
	build_default_reqwest_client_for_route(&http_client_factory, &request_url, route_class)
	.map_err(std::io::Error::from)
	})
	.await
	.map_err(std::io::Error::other)?
	let permit = ROUTE_AWARE_CLIENT_BUILD_PERMIT
	.acquire()
	.await
	.map_err(std::io::Error::other)?;
	tokio::task::spawn_blocking(move || {
	let _permit = permit;
	build_default_reqwest_client_for_route(&http_client_factory, &request_url, route_class)
	.map_err(std::io::Error::from)
	})
	.await
	.map_err(std::io::Error::other)?

[bolinfest]

Fixed in 130fc9e36209. The acquired semaphore permit is now moved into the spawn_blocking closure, so cancelling or timing out the outer future cannot release the permit while the already-started PAC/WinHTTP lookup is still running.