Feature request: render ReadMediaFile results inline in the TUI (kitty/iTerm2 image protocols)

Summary

The TUI already detects image-capable terminals (Ghostty/kitty → kitty graphics protocol, iTerm2 → 1337;File) and renders pasted images inline in user messages. However, images produced by tools — specifically ReadMediaFile results — are shown only as a chip with a metadata summary (mime type / size / path), not as an inline image.

Other terminal agents (e.g. pi) render images inline in the transcript whenever a tool reads/generates one, which makes image-generation and screenshot-review workflows much smoother.

Desired behavior

When caps.images is "kitty" or "iterm2", render the image payload of ReadMediaFile (and similar media-producing tool results) inline in the tool card / transcript, the same way pasted image attachments are rendered in user messages. Fall back to the current chip summary on terminals without image support.

Environment

• kimi-code 0.28.1 (macOS arm64, single binary)
• Terminal: Ghostty (detected as kitty-capable)

Notes

From inspecting the 0.28.1 binary: src/tui/components/messages/user-message.ts has the supportsInline = caps.images === "kitty" || caps.images === "iterm2" inline-render path for attachments, while src/tui/components/messages/tool-renderers/media.ts only parses the ReadMediaFile output into a chip + summary. The web UI already renders these media results as thumbnails; this request is only about the TUI.

Start with src/tui/components/messages/tool-renderers/media.ts and compare its ReadMediaFile handling with the inline attachment path in src/tui/components/messages/user-message.ts. Trace how image-capable terminal support is exposed through caps.images, then verify that supported terminals render media inline while others retain the chip summary; use the existing TUI media and attachment tests if available.