fix(telegram): stop typing indicator from lingering after response delivery

[mpesce]

Problem

Telegram shows a "typing..." indicator that persists for ~5 seconds after the agent response has already been delivered. This happens because:

1. Telegram has no native "stop typing" API — the indicator self-expires after ~5s
2. The gateway's _keep_typing() loop (in base.py) fires send_typing() every ~2s to keep the bubble alive during processing
3. When the agent finishes and the response is delivered, the gateway calls adapter.stop_typing(chat_id) at gateway/run.py:8441
4. For Telegram, this is a no-op — TelegramAdapter inherits the base class's empty stop_typing()
5. The _keep_typing background task is still alive — cancellation hasn't propagated yet
6. One last send_typing() fires, resetting Telegram's 5s timer

Platforms with native stop-typing APIs (Slack, Signal, Matrix) override stop_typing() to actively clear the indicator. Telegram can't, but it can suppress the next refresh.

Fix

Add stop_typing() to TelegramAdapter that pauses the typing refresh loop using the existing _typing_paused mechanism from BasePlatformAdapter. No new infrastructure needed — _typing_paused already exists (line 1350), _keep_typing already checks it (line 2304), and the finally block already cleans it up (line 2349).

async def stop_typing(self, chat_id: str) -> None:
    self._typing_paused.add(chat_id)

Testing

Tested on systemd 259 (Ubuntu) with Telegram Bot API. After the fix, the typing indicator fades naturally within ~5s of the final send_typing() call rather than getting a late refresh after the response is already visible.

[alt-glitch]

Competing with #29172 (comprehensive, all delivery paths + stream consumer) and #29595 (lightweight, reuses notify flag) — all three fix #29175. This approach is Telegram-specific using the existing _typing_paused mechanism.

[mpesce]

Closing in favor of #29595 — the notify-flag approach is strictly better for Telegram: it prevents the re-arm before it happens rather than racing to suppress it after, avoids new infrastructure, and has regression tests. Three well-considered approaches for the same bug is a good sign for the project. Thanks for the review.

[mpesce]

Closed in favor of #29595.