Bug Description

When using Hermes on Telegram, replying with a local image via the documented MEDIA:/absolute/path/to/file.png mechanism can result in Telegram receiving plain text containing the local filesystem path instead of a native uploaded photo attachment.

This was observed while trying to share a browser_vision screenshot.

Expected Behavior

Per the Hermes docs and Telegram adapter implementation, a response containing MEDIA:/absolute/path/to/file.png should be intercepted by the gateway and delivered as a native Telegram photo upload.

Actual Behavior

The user sees a plain text message like:

🖼️ Image: /data/repo/home/cache/screenshots/browser_screenshot_2015cd1a9e244f10bc0e8a06269a34c4.png

instead of receiving an attached image.

Why this looks like a bug

I checked the public docs and upstream code:

• website/docs/user-guide/features/browser.md says browser screenshots shared on messaging platforms should be sent as native photo attachments via the MEDIA: mechanism.
• gateway/platforms/base.py extracts MEDIA:<path> tags.
• gateway/platforms/telegram.py implements send_image_file(...) to upload a local image as a Telegram photo.

So the intended behavior appears to be native attachment delivery, not path echoing.

Steps to Reproduce

1. Use Hermes via Telegram DM.
2. Call browser_vision on any page so it returns a local screenshot_path.
3. Reply with exactly:
   MEDIA:/absolute/path/to/the/screenshot.png
4. Observe what Telegram receives.

Observed Example

The screenshot path returned by browser_vision was:

/data/repo/home/cache/screenshots/browser_screenshot_2015cd1a9e244f10bc0e8a06269a34c4.png

The file existed on disk and was non-empty (~980 KB), but Telegram still showed the path as text instead of a photo attachment.

Environment

• Platform: Telegram DM
• Hermes deployment: cloud-hosted/containerized deployment
• Screenshot source: browser_vision
• File path was absolute and existed on disk

Notes / Suspicions

This may indicate one of the following:

• the MEDIA: tag is not being intercepted in this response path
• the platform send pipeline is falling back to the base adapter text behavior before Telegram native upload occurs
• some gateway/rendering path is converting the intended attachment send into plain text

I have not yet isolated whether this is a general Telegram issue or specific to certain deployment/gateway paths, but the behavior contradicts both the docs and the intended adapter flow.