fix(gateway): queue voice/audio messages instead of interrupting with empty text

[chaizijun1]

Summary

• When a voice/audio message arrives while an agent is already running, the gateway interrupts the agent with event.text — but voice messages haven't been through STT transcription yet, so event.text is empty. This causes the agent to hang.
• Photos already have dedicated queueing logic that avoids interrupting the running agent. This PR applies the same merge_pending_message_event pattern to MessageType.VOICE and MessageType.AUDIO.

Reproducer

1. Send a voice message to the Telegram bot
2. Before the agent finishes responding, send a second voice message
3. Expected: second voice is queued and processed after the first completes
4. Actual: agent hangs indefinitely (interrupted with empty text)

Changes

• gateway/run.py: Add voice/audio check between the existing photo queueing block and the _AGENT_PENDING_SENTINEL check (+12 lines)

Test plan

• Send two consecutive voice messages in quick succession — second should be queued and processed after the first
• Send a voice message while agent is processing a text message — should queue without interrupt
• Send a text message while agent is processing — should still interrupt normally (existing behavior preserved)
• Verify photo queueing still works as before

🤖 Generated with Claude Code

[chaizijun1]

Hi team, gentle bump on this one. This is a bug fix for voice/audio messages causing agent hangs when sent in quick succession. The fix mirrors the existing photo queueing pattern. Happy to adjust anything if needed!

[teknium1]

Thanks for this, and for the clear reproducer — the empty-event.text voice hang was a real bug.

It's since been fixed on main by a more complete mechanism (commit d55304c, "fix(gateway): transcribe voice messages during active agent runs"). Rather than forcing voice/audio into queue-only, main now transcribes the pending voice/audio event before signaling the running agent — both on the interrupt path (gateway/run.py ~L17311) and the post-run dequeue path (~L17712) — so the interrupt carries the real transcript plus the 🎙️ echo back to the user. That keeps voice messages able to interrupt (same UX as text), which this PR's queue-only approach would have removed.

Closing as superseded — your diagnosis was correct, the maintainer fix just preserves the interrupt behavior. Appreciate the contribution!