fix(opencode): wire databricks-openai provider for GPT-5 / Codex

[dgokeeffe]

Fixes #97.

Wires the third Databricks model family (GPT-5 / Codex Responses) into the
OpenCode adapter alongside Anthropic and Gemini. Mirrors the pattern the Pi
adapter (src/ucode/agents/pi.py) already uses to support the same three
families.

What changed

Three small wires, one new test class, one supporting test in test_databricks.

File	Change
src/ucode/cli.py	want_codex now includes opencode in the consumer set; codex discovery results land in opencode_models["openai"].
src/ucode/databricks.py	build_opencode_base_urls(workspace) returns a third "openai" key pointing at /ai-gateway/codex/v1 (matches build_pi_base_urls).
src/ucode/agents/opencode.py	render_overlay writes a databricks-openai provider using @ai-sdk/openai with per-model useResponsesApi: true. default_model() falls back to codex before gemini (codex are the primary code models). PROVIDER_KEYS extended so stale-config cleanup tracks the new provider.
tests/test_agent_opencode.py	New TestRenderOverlayCodex class — 12 assertions covering provider rendering, base URL, useResponsesApi per model, headers, model prefixing, managed keys. Also extended TestOpencodeDefaultModel with a codex-ahead-of-gemini fallback test.
tests/test_databricks.py	test_returns_openai_codex_gateway ensures build_opencode_base_urls exposes the codex base URL.

Net diff: +158 / -2 across 5 files.

Verification

Unit tests

$ uv run pytest tests/test_agent_opencode.py tests/test_databricks.py -q
104 passed in 4.72s

$ uv run pytest -q --deselect tests/test_e2e_user_agent.py::TestCodexUserAgent::test_user_agent_arrives_at_gateway
547 passed, 27 skipped, 1 deselected in 28.20s

(The one deselected case is a pre-existing local-environment break in the codex profile-config migration — fails identically on origin/main without these changes. Not a regression from this PR.)

$ uv run ruff format src/ tests/
39 files already formatted
$ uv run ruff check .
All checks passed!

End-to-end against stock OpenCode 1.4.11

I drove the live ucode internals against logfood (AI Gateway v2 enabled,
serving 3 Claude + 4 Gemini + 12 GPT-5 / Codex models), rendered an
opencode.json into a tmp XDG_CONFIG_HOME, and ran the stock
opencode-ai@1.4.11 binary against it.

Before this PR (the codex provider is absent from opencode.json):

$ XDG_CONFIG_HOME=$TMP OAUTH_TOKEN=$TOKEN opencode run \
    --model databricks-openai/databricks-gpt-5-5 "say hi in 5 words"
> build · databricks-gpt-5-5
Error: Model not found: databricks-openai/databricks-gpt-5-5.

After this PR (the provider is wired in):

$ XDG_CONFIG_HOME=$TMP OAUTH_TOKEN=$TOKEN opencode run \
    --model databricks-openai/databricks-gpt-5-5 "say hi in 5 words"
> build · databricks-gpt-5-5
Error: "text part msg_01285cc2f9fe616b6f128ad2e9ebc6049c0... not found"

The model is now reachable end-to-end. OpenCode connects, posts to
/ai-gateway/codex/v1/responses, receives a tool-call output, and then trips
on a separate downstream bug (oversized response item IDs that violate
OpenAI's documented <= 64 limit on the Responses contract — filed as
#99). That second hop is
out of scope for this PR; the relevant change here is that the connection
now succeeds where it previously errored before any wire activity.

Claude and Gemini paths through the same managed config still respond
successfully against logfood and lakemeter — no regressions in the
existing two families:

$ opencode run --model databricks-anthropic/databricks-claude-sonnet-4-6 "say hi in 5 words"
> build · databricks-claude-sonnet-4-6
Hi there, hope you're doing well!

Acknowledgement of related issues

This PR addresses #97 only. It is one of three blockers identified for using
ucode + stock OpenCode without a Databricks-aware fork:

• ucode opencode adapter omits databricks-openai provider — opencode loses access to GPT-5 / Codex Responses models #97 (this PR) — codex provider missing from OpenCode adapter.
• OpenCode 1.4.11 (stock) returns "Forbidden: Invalid Token" against ucode-managed opencode.json — works against a Databricks-aware fork #98 — Forbidden: Invalid Token against stock OpenCode 1.4.11. Cannot reproduce as of 2026-05-28 with opencode-ai@1.4.11 against logfood or lakemeter; Claude requests succeed with the current apiKey + headers.Authorization shape. Will follow up on the issue with detail.
• Multi-turn GPT-5 conversations fail through ucode + stock OpenCode — Databricks Responses returns itemIds >64 chars that OpenAI rejects on echo #99 — oversized itemId rejection on multi-turn GPT-5 conversations. Independent server- and client-side workaround required; would be addressed in OpenCode upstream, not here.