Feature: Support rendering Gemini image generation output in TUI

[xpolb01]

Summary

When Gemini models generate images via responseModalities: ["IMAGE"], the response arrives in OpenCode as a FilePart (with type: "file", mime: "image/png", and a url), but the TUI event handlers silently drop it because there's no handler for type: "file" parts.

The full pipeline works up to the rendering layer:

Stage	Status	Details
OpenCode → Antigravity → Gemini API	✅	Request proxied correctly
Gemini API response	✅	Returns FilePart with mime: "image/png" + URL
SDK parsing	✅	Detects image/* content-type, creates FilePart
TUI rendering	❌	No handler for file/image part types

Current Behavior

1. User asks Gemini to generate an image
2. Gemini generates the image successfully
3. OpenCode SDK receives the response and creates a FilePart
4. TUI event handler (handleMessagePartUpdated) only handles: text, thinking, reasoning, tool, tool_use, tool_result, step-start, step-finish
5. Image part is silently ignored — nothing is displayed

Expected Behavior

When a FilePart with an image MIME type arrives, the TUI should render it. Options:

• Option A: Print the file URL/path and suggest opening in browser
• Option B: Use terminal image protocol (iTerm2/Kitty/Sixel) for inline display
• Option C: Save to a temp/output file and print the path

Additional Context

• The antigravity-provider-configuration already declares image in output modalities: ["text", "audio", "image", "video", "pdf"]
• The look-at tool supports image input (vision/analysis), but this is about image output from Gemini
• Google's Gemini API returns images inline as base64-encoded PNG/JPEG in inlineData fields
• Relevant models: gemini-3.1-flash-image-preview, gemini-3-pro-image

Environment

• oh-my-opencode: latest
• opencode-antigravity-auth: 1.6.0
• OpenCode: latest
• OS: macOS (darwin/arm64)

[acamq]

The TUI is part of anomalyco/opencode. This repository is only a plugin for opencode and this issue should be opened upstream in anomalyco/opencode.