feat(assemblyai): warn when audio stops flowing to the WebSocket

[gsharp-aai]

Summary

Extends the recv-silence warning with a symmetric send-side warning.

The recv-silence warning on its own can't distinguish "AssemblyAI is stalled" from "the plugin stopped receiving audio from upstream and is correctly silent." When a session appears wedged, both interpretations are on the table and the recv-side log alone can't separate them.

This adds the complementary check: inside the same 15s recv-silence block, if _last_frame_sent_at is also >15s old, log AssemblyAI no audio frames sent for Ns session=<id>. The two absence-of-activity warnings appear back-to-back during a stall, giving an unambiguous diagnosis:

send-stopped warning	recv-silence warning	Diagnosis
silent	firing	AssemblyAI stalled — frames flowing, no response
firing	firing	Upstream stalled — plugin got no audio
silent	silent	healthy

Implementation

• Adds self._last_frame_sent_at: float | None = None, set on every successful ws.send_bytes(...) in send_task.
• In recv_task, the existing if consecutive_timeouts % 3 == 0: block now also checks send-side idleness and logs the second warning when applicable.
• No new watchdog coroutine; reuses the 15s cadence already established.
• Guarded on _last_frame_sent_at is not None so it doesn't fire during the initial connect window before any audio has been sent.

Impact

• Warning-level only, and only when both sides are idle together.
• Healthy sessions: silent.
• Overhead: one time.time() assignment per audio frame.

Test plan

• make format lint type-check pass
• Healthy session: no send-stopped warning emitted
• Simulated upstream stall (close input_ch while keeping WS open): both warnings fire at 15s, 30s, 45s
• Simulated AAI stall (mock WS that accepts but never responds): recv-silence fires, send-stopped stays silent

[gsharp-aai]

Closing — livekit#5476 has merged upstream, so this is now moot. Re-opening as a fresh PR against livekit/agents:main.