[feat] register openai as built-in openai-compatible provider

[EYH0602]

Summary

Follow-up to merged PR #2. Lets callers address OpenAI models directly with the slug form openai/<model-id> (e.g. openai/gpt-5-nano) — same dispatch path as vllm/<model-id>, no models.json entry required.

• New built-in provider entry in packages/cli/src/models/openAICompatibleProviders.ts:
  • defaultBaseURL: https://api.openai.com/v1
  • baseURLEnv: OPENAI_BASE_URL (override for OpenAI-compatible proxies)
  • apiKeyEnv: OPENAI_API_KEY
  • supportsStructuredOutputs: true (server-side response_format: { type: "json_schema" })
• Also bundles the smaller fixes from earlier on the branch that landed after PR [feat] support OpenAI-compatible endpoints (vLLM) as judge/target #2:
  • drop hardcoded 300-token cap on user-message generation
  • enable json_schema response_format for vLLM structured outputs
  • auto-resolve served model id against /v1/models
• .env.example documents OPENAI_API_KEY / OPENAI_BASE_URL next to the existing gateway and vLLM keys; yarn kora:env already loads .env via node --env-file, so OpenAI direct follows the same flow as the Vercel AI gateway.
• README has a quick OpenAI direct example.
• Tests updated: two cases previously used openai/gpt-4o as the example of an unknown prefix; replaced with a synthetic nonprovider/... slug. Added an explicit positive test that the openai prefix resolves to api.openai.com.

Gateway-routed OpenAI models (named entries like gpt-4o, gpt-5.2:high in models.json) are unchanged.

Test plan

• yarn tsbuild — passes
• yarn test — 182/182 passing
• Smoke test against api.openai.com: yarn kora run openai/gpt-5-nano openai/gpt-5-nano --judges openai/gpt-5-nano --limit 10 — 10/10 scenarios scored, judge MechanismAssessment JSON validated server-side.
• vLLM regression: same smoke run with vllm/Qwen3-30B-A3B-Instruct-2507 — 1/1 passes.

[fenfenai]

Review Summary

Reviewed 10 files, 89 additions / 10 deletions across bug detection, error handling, type design, test coverage, comment quality, and guidelines compliance.

No findings at confidence ≥75. Approving.

Positive observations

• supportsStructuredOutputs is added as optional on both OpenAICompatibleProvider and VOpenAICompatibleModelConfig, with ?? false defaults at both fromParsedSlug and fromConfig — safe asymmetric design (opt-in per provider, conservative for unknown configs).
• The structured-output fallback in getStructuredResponse already handles json_schema-rejecting models via prompt injection + extractJson, so flipping the flag on for openai/vllm degrades safely.
• Tests for the unknown-prefix case were correctly migrated from openai/gpt-4o to a synthetic nonprovider/... slug — necessary and easy to forget.
• Comments explain the why (e.g., the json_object vs json_schema distinction and the consequence for strict MechanismAssessment schemas).
• .env.example and README updates align with yarn kora:env's --env-file flow.

Lower-confidence observations (FYI, below report threshold)

• generateUserMessage.ts removal of maxTokens: 300 also widens scope to gateway-routed user models — intentional per the PR description and updated test comment, but worth a heads-up since gateway callers have no <PREFIX>_MAX_TOKENS equivalent.
• End-to-end propagation of supportsStructuredOutputs from provider entry through ResolvedTarget to createOpenAICompatible isn't asserted by a test. The flow is short and reads correctly; minor coverage gap, not a bug.