Make gateway send generated images and evaluate GIF support

[crankshift]

Summary

Make the gateway capable of returning generated visual media to the user, starting with still images and including a feasibility evaluation for GIF generation and delivery.

Context

The gateway currently focuses on text, voice, and existing media attachment flows. Visual generation would let users ask OpenCode to create image outputs and receive them through the configured messenger adapter. GIF support needs explicit discovery before implementation because it may have materially different complexity, token usage, runtime duration, file size, device requirements, and provider/tooling constraints.

Acceptance Criteria

• Define a messenger-neutral flow for generated visual outputs so core gateway logic does not depend on Telegram-specific types.
• Support sending generated still images back to the user through the Telegram adapter, including safe temporary file handling and cleanup.
• Document or implement the OpenCode/tool contract the gateway expects for generated image artifacts.
• Evaluate GIF support separately, including implementation complexity, token and cost implications, file size limits, runtime/device requirements, and adapter delivery constraints.
• If GIF support is feasible, capture a proposed implementation path; if not, document why it should be deferred.
• Add focused tests for image delivery behavior and any GIF feasibility decision logic or documentation introduced.

Notes

Keep generated media handling privacy-safe: do not persist secrets, provider URLs, raw prompts, chat IDs, user IDs, or local absolute paths beyond existing non-secret state boundaries. Preserve the architecture boundary between core gateway media orchestration and Telegram-specific delivery.