Codex API-key preflight probes the default endpoint when only openai_base_url is set #1218

Suggested labels: bug, data-governance

Problem

This was traced in code while working on #1210; it has not been reproduced against a live endpoint.

• Where: addCodexProviderRoute in packages/runtime/src/templates/smithers/agents/codex.tsx sets OPENAI_BASE_URL only from a model_provider table in the Codex config.toml.
• When it happens: a project that routes Codex through a gateway with only a top-level openai_base_url (no model_provider) and uses API-key auth.
• What goes wrong: OPENAI_BASE_URL stays unset. Smithers' API-key preflight then probes the inherited or default OpenAI endpoint with the configured key, instead of the gateway Codex will actually call.
• Why it matters: the function's own comment says it exists to prevent this: "an ambient endpoint can receive the configured provider's credential during preflight".
• Impact: Smithers logs failed preflight probes as non-blocking, so this does not stop a campaign. It does send the credential to an endpoint the operator did not acknowledge.

Since #1210, planning digests that config shape as the built-in openai provider at the openai_base_url endpoint. The adapter's preflight environment should match.

Proposed fix

When the selected provider is the built-in openai provider and a non-empty top-level openai_base_url is set, addCodexProviderRoute also sets OPENAI_BASE_URL to it for the preflight, mirroring the route digest in codexRouteConfig (packages/runtime/src/data-governance.ts).

Acceptance criteria

• With openai_base_url = "<gateway>" and no model_provider, the preflight probes <gateway>, never the default endpoint.
• An empty openai_base_url keeps today's behaviour, since Codex ignores it.