fix(telegram): refresh general request pool after pool timeout

[izumi0uu]

What does this PR do?

Fixes the Telegram gateway send-path failure behind #53524. When PTB reports a pool timeout on send_message(), the request was never sent, so the adapter now resets the general Bot API request pool before retrying. That gives the next attempt a fresh httpx client instead of hammering the same exhausted pool.

The old behavior was wrong because the send path treated pool timeout as retryable but left _request[1] untouched, so retries could keep failing against a wedged general request pool.

Related Issue

Fixes #53524

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✅ Tests (adding or improving test coverage)

Changes Made

• Added a small helper to drain either PTB request pool in place.
• Kept polling reconnect on _request[0] only, and reset the general send/edit pool on send-side pool timeouts.
• Added a regression test that verifies the general request pool is refreshed before the retry succeeds.

How to Test

1. Run python -m pytest tests/gateway/test_telegram_thread_fallback.py -k "pool_timeout or refresh_general_pool" -q
2. Run python -m pytest tests/gateway/test_telegram_send_path_health.py tests/gateway/test_telegram_closewait_limits_31599.py -q
3. Confirm both commands pass.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run targeted Telegram tests and they pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• N/A

Screenshots / Logs

./.venv/bin/python -m pytest tests/gateway/test_telegram_thread_fallback.py -k "pool_timeout or refresh_general_pool" -q -> 3 passed
./.venv/bin/python -m pytest tests/gateway/test_telegram_send_path_health.py tests/gateway/test_telegram_closewait_limits_31599.py -q -> 6 passed

Remaining Risks

• I did not run a long-lived real Telegram gateway session to reproduce the 12h live symptom end-to-end.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #53622 — both fix #53524 with the same mechanism (reset PTB's general Bot API request pool _request[1] after a confirmed send-side pool timeout, leaving the polling pool _request[0] untouched) across the same two files. #53622 was opened ~2.5 minutes earlier, so it's treated as canonical. Related pool-exhaustion cluster: #38812, #43333, #35624, #41391 (same #31599 family). Maintainer picks one to merge.

[teknium1]

Closing as a duplicate of #53524's fix. Both your PR and #53622 by @yungchentang implemented the same general send-pool drain on pool timeout; #53622 was submitted first and included an asyncio.Lock to serialize concurrent drains, so it was the one salvaged in PR #54121 (#54121). Your shared _drain_bot_request_pool helper was a nice DRY shape — thanks for the contribution and the diagnosis.