feat(openai): support the gpt-image-2.5 line, default to gpt-image-2.5-flare

[tombensim]

What

The openai image plugin now knows OpenAI's GPT Image 2.5 line and defaults to it.

• DEFAULT_MODEL moves from gpt-image-2 to gpt-image-2.5-flare for both image.create and image.edit.
• model inputs on both actions list gpt-image-2.5-flare and gpt-image-2.5-sunburst.
• quality inputs document the 2.5-only xhigh / max values (plus auto).
• size inputs document the 2.5 rule: any WIDTHxHEIGHT with both sides multiples of 16, aspect between 1:3 and 3:1, no edge over 3840px, experimental above 2560x1440, or auto.
• The defaultModel connection hint now points at gpt-image-2 as the way to pin the older line.

Facts are from OpenAI's model pages and image-generation guide (gpt-image-2.5-flare-2026-09-08 / gpt-image-2.5-sunburst-2026-09-08 snapshots).

Why

Same reasoning as 167c972 (default to gpt-image-2): the newest model is the right zero-config choice. Flare is OpenAI's own default and matches gpt-image-2 quality at up to half the latency; sunburst is there for precision edits when a caller asks for it. Per-call model and connection defaultModel precedence is unchanged, so anyone pinned to gpt-image-2 sees no difference.

No request-shape changes were needed: the gpt-image branch already sends output_format (2.5 uses the same contract), and quality / size were already passed through verbatim.

Tests

packages/runline/src/tests/image-edit-plugins.test.ts (17 → 23 tests):

• image.create and image.edit default to gpt-image-2.5-flare.
• image.create precedence: per-call > connection defaultModel > default (edit already had this; both now exercise a 2.5 id and a gpt-image-2 pin).
• Both 2.5 ids take the output_format: png branch and never send response_format; dall-e-3 still gets response_format: b64_json.
• xhigh / max / auto quality and a custom 1536x864 / auto size reach the API unmodified on both actions.
• Both actions' model descriptions name both 2.5 models and the quality descriptions name xhigh and max.

bun --filter runline build, bun --filter runline test and bun run check run clean apart from two things that are identical on untouched main: the engine-robustness sandbox-OOM test fails locally on this machine, and biome reports one unused suppression comment in engine-onaction.test.ts.

Not in this PR

• No client-side validation of the 2.5 size rules — the API's 400 is surfaced as-is, matching how the plugin treats every other model-specific constraint.
• No new inputs (background, output_format, output_compression); those are a separate feature.
• No release bump; vex pins runline 0.29.0 and will pick this up on the next release.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U4xJ2FZDNXyW98r5AsnzUT