fix(gemini): surface model-generated images instead of dropping them

[IngTian]

Issue for this PR

Closes #41467

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Gemini image models return generated images as inlineData, but nothing carries them into the session, so the image is dropped and the user sees only the model's text. The request is still billed.

Two gaps, so three small changes:

1. LLMEvent.File — there was no event to carry media. Media arrives whole rather than as deltas, so there's no start/delta/end triple.
2. Gemini decoder emits it for inlineData, closing any open reasoning block first so media doesn't land inside one.
3. SessionProcessor persists it as a file part, closing the current text block first to keep ordering. It reuses the same image normalization tool attachments already use, so an oversized generated image can't blow up the next request; if normalization is unavailable it keeps the original rather than dropping the image.

Also: toModelMessages replays assistant file parts and the Gemini request builder accepts assistant media, so a follow-up turn ("make it brighter") can edit the generated image instead of starting over. Under stripMedia (compaction/overflow) it degrades to a text placeholder like other media.

Note responseModalities: ["TEXT", "IMAGE"] must still be set in the model's provider options, or Vertex returns text only.

How did you verify your code works?

Tests: packages/llm 299 pass, packages/opencode session suite 399 pass / 0 fail, typecheck clean on both.

New coverage — a Gemini decoder test asserting a file event is emitted for inlineData alongside the text, a processor test asserting the image is persisted as a file part, and two toModelMessages tests for replay and stripMedia. I checked the processor test fails without the fix, so it's real coverage rather than a tautology.

I also updated the existing rejects unsupported assistant media content test, which asserted the old behavior ("only support text, reasoning, and tool-call content for now") — that's the placeholder this PR fills in.

Not verified: live Vertex traffic. Decoder behavior is covered by a synthetic SSE fixture rather than a real provider response.

Screenshots / recordings

Not a UI change — this makes the file part exist; existing clients render it.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[IngTian]

Two notes for whoever picks this up.

Relationship to #40126. That PR fixes the same gap on v2 and is further along — if v2 is where you want this, close mine in its favour. I opened this one because dev is where releases are cut (1.18.15 is the current one) and the branches have diverged, so #40126 will not reach dev users: packages/opencode doesn't exist on v2, and v2 currently sits 1267 commits behind with no merges from dev in its recent history. Happy to be wrong about that if you're planning a sync.

Pairs with #41463. On dev these two are sequential, not alternatives. #41463 stops Vertex rejecting the request outright ("model does not support function calling"); this PR makes the returned image visible. With only #41463 you get a billed request whose image is silently dropped; with only this one the request still 400s unless the user hand-writes an agent with permission: {"*": deny}.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found a potentially related PR:

PR #40126: feat(session): support Gemini image generation
#40126

This PR appears to be related as it also addresses Gemini image generation support. You should check whether this earlier PR covers similar ground or if there's any overlap in approach between the two PRs.