[P0.28] `--engine codex` refuses to run without OPENAI_API_KEY even when the codex CLI is logged in

[frankbria]

Found while rewriting the Codex adapter (#914 / PR #1009).

Problem

cf work start --engine codex --execute and cf work batch run --engine codex both call require_openai_api_key() (codeframe/cli/app.py:2543 and :3936), which prints an error and exits when OPENAI_API_KEY is unset.

But the codex CLI does not need OPENAI_API_KEY — it authenticates via codex login (ChatGPT plan credentials in ~/.codex/auth.json). The live end-to-end demo on PR #1009 drove the real codex app-server to completion with no OPENAI_API_KEY set at all.

So for the common case (a developer who ran codex login), the advertised --engine codex is unusable from the CLI even though the adapter and the binary both work.

Evidence

• codeframe/cli/app.py:2543 — if engine == "codex": require_openai_api_key()
• codeframe/cli/app.py:3936 — same gate on the batch path
• codeframe/cli/validators.py:44 — require_openai_api_key raises typer.Exit when unset
• CodexAdapter.requirements() likewise advertises OPENAI_API_KEY to cf engines check

Acceptance criteria

• --engine codex runs when the codex CLI is authenticated by codex login, with no OPENAI_API_KEY in the environment
• OPENAI_API_KEY still works as an alternative (codex honours it), and a genuinely unauthenticated codex still fails fast with a message naming both options
• cf engines check reports codex as ready in the logged-in case instead of flagging a missing key
• Tests cover: logged-in-no-env-key, env-key-no-login, and neither

Notes

Detecting the login means checking for codex's credential file (or shelling out to a codex auth/status command) rather than treating an env var as the only proof of auth. Out of scope for #914, which was confined to the wire protocol.