Bug: read_audio fails on Telegram voice messages with provider/upload errors

[mrgoonie]

Summary

read_audio is currently failing to process Telegram voice messages in a group chat, preventing the assistant from transcribing or understanding user voice input.

Context

Platform: Telegram group chat
Feature/tool: read_audio
Input type: Telegram voice message (<media:voice>)

Reproduction observed

1. User sends a Telegram voice message.
2. Assistant calls read_audio with the provided media_id.
3. Tool fails instead of returning transcription.
4. User retries / sends another voice message.
5. Tool still fails with provider/upload errors.

Actual results

Two failure modes were observed:

Attempt 1

Audio analysis failed: all providers failed: read_audio: unsupported audio route for provider bailian (type dashscope) model qwen3.6-plus; supported routes are Gemini File API, native OpenAI input_audio, or OpenAI-compatible transcription models

Attempt 2 after resending voice

Audio analysis failed: all providers failed: gemini file API: upload: init upload HTTP 403

There was also an intermediate retry where the old media was no longer available:

no audio files available in this conversation. The user may not have sent an audio file.

Expected result

read_audio should successfully access Telegram voice messages and return a Vietnamese transcription, or gracefully fall back to a supported STT provider/route.

Impact

Voice messages in Telegram cannot be handled. The assistant has to ask users to type manually, which breaks UX in mobile/group-chat use cases.

Notes

This happened in live Telegram group usage. The second failure suggests either media upload permission/config issue with Gemini File API or missing provider fallback when upload returns 403.