neon: route GPT-5 via Responses API + mark image output

[andrelandgraf]

Summary

Stacked on #3019 (branched off neon-catalog-sync-2026-07). Once #3019 merges, this PR's diff reduces to the 12 GPT‑5 model files below.

Two related corrections to the Neon provider's GPT‑5 models, both verified live against the gateway:

1. Route GPT‑5 via the Responses API, not mlflow chat-completions. The Neon provider's default api is …/ai-gateway/mlflow/v1, but the GPT‑5 models are served on the OpenAI Responses route (…/ai-gateway/openai/v1). The codex variants are Responses-only — mlflow returns 400 "model … is not available on the chat_completions endpoint". So the current entries silently break for consumers that use the provider default. Each of the 12 GPT‑5 models now carries a per-model [provider] override:

   [provider]
   npm   = "@ai-sdk/openai"
   api   = "${NEON_AI_GATEWAY_BASE_URL}/ai-gateway/openai/v1"
   shape = "responses"

   (Same per-model override pattern Amazon Bedrock uses for openai.gpt-5.5 → a /openai/v1 Responses endpoint.) The provider-level default stays mlflow/v1 for the rest of the catalog (Claude/Gemini/Llama/Qwen), which work on chat-completions.

2. Mark modalities.output with "image". All 12 GPT‑5 models generate images via the Responses image_generation built-in tool — verified live (each returned a real JPEG, ~33–38 KB). Now that they're pinned to the Responses route where that tool works, output: ["text","image"] is accurate. This also gives the Neon docs an "Image" category via the standard modalities.output.includes("image") filter (same convention OpenRouter uses for its GPT-image models).

Nothing changes for the non-GPT‑5 models.

Models changed (12)

gpt-5, gpt-5-mini, gpt-5-nano, gpt-5-1, gpt-5-2, gpt-5-4, gpt-5-4-mini, gpt-5-4-nano, gpt-5-3-codex, gpt-5-2-codex, gpt-5-1-codex-max, gpt-5-1-codex-mini

Notes

• modalities.input is preserved per model (some GPT‑5 add pdf); only output gains image.
• Consumer support for per-model [provider] overrides varies. models.dev/opencode honor them; some flat-registry consumers (e.g. Mastra's models.dev gateway) currently route by provider id and ignore per-model overrides — I'm opening an upstream Mastra PR to make per-model shape/api overrides work generally.

Test plan

• Local parse + base_model merge validation: all 36 Neon models valid; 12 GPT‑5 resolve to modalities.output ⊇ [image] and provider.shape = responses.
• CI schema validation.