fix(telegram): honor HERMES_TELEGRAM_HTTP_* timeouts in standalone send path

[garyyang1001]

What does this PR do?

Makes the standalone Telegram send path (tools/send_message_tool.py::_send_telegram, used by agent / TUI / cron / hermes send) honor the same HERMES_TELEGRAM_HTTP_* timeout env knobs as the in-gateway adapter, with the same defaults (pool 8s / connect 10s / read 20s / write 20s).

Today that path constructs telegram.Bot(token=...) with PTB's default HTTPXRequest, which times every request out at 5s. Telegram can hold sendDocument/sendPhoto responses for 30s+ when a bot is under flood control, so every standalone media send fails with Timed out — surfaced to the caller as the misleading No deliverable text or media remained after processing MEDIA tags — even though the upload itself succeeds server-side (risking silent duplicates on retry).

Real-world incident: a production deployment lost two days of scheduled document deliveries (all hermes send MEDIA pushes timing out every 5-minute retry sweep) while curl uploads of the same files completed in <2s. Raising the read timeout via the (previously gateway-only) env knob fixed it — this PR makes that knob work for the standalone path too, and aligns the defaults so the two send paths behave consistently.

Related Issue

No existing issue found (searched telegram timeout, send_message_tool timeout, telegram media timed out; closed PRs #47238/#47923 addressed retry for text sends, not the media/HTTPXRequest timeout configuration).

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/send_message_tool.py — standalone Bot() construction now builds HTTPXRequest with HERMES_TELEGRAM_HTTP_POOL/CONNECT/READ/WRITE_TIMEOUT (defaults matching plugins/platforms/telegram/adapter.py: 8/10/20/20s), on both the proxy and direct branches. Malformed env values fall back to defaults. If telegram.request is unavailable, falls back to a plain Bot(token=...) as before.
• tests/tools/test_send_message_telegram_timeouts.py — new: default values, env overrides, malformed-env fallback, proxy branch carrying timeouts.
• tests/tools/test_send_message_telegram_proxy.py — updated test_no_proxy_env_uses_plain_bot to the new contract (direct branch passes a timeout-tuned request=, still no proxy=, still no get_updates_request=).

How to Test

1. pytest tests/tools/test_send_message_telegram_timeouts.py tests/tools/test_send_message_telegram_proxy.py -q → 6 passed.
2. Reproduce the incident: from a machine whose bot is flood-limited (or with HERMES_TELEGRAM_HTTP_READ_TIMEOUT=1 to simulate), run hermes send --to telegram:<chat> "hi MEDIA:/path/to/file.docx" → fails with Timed out before this fix at default settings when Telegram responds slowly.
3. With this fix, set HERMES_TELEGRAM_HTTP_READ_TIMEOUT=120 in ~/.hermes/.env → same command delivers.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(telegram): ...)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature
• I've run the relevant tests: pytest tests/tools/ -q — the tests touching this area all pass; the 60 pre-existing failures on my machine (voice/wake-word/web-tools env-dependent) fail identically on a pristine origin/main checkout
• I've added tests for my changes
• I've tested on my platform: macOS 15 (Darwin 25.4)

Documentation & Housekeeping

• Docs: N/A — the env vars already exist for the gateway adapter and were undocumented; this PR extends where they apply (happy to add a docs entry if you'd like them documented)
• cli-config.yaml.example: N/A — no config keys added
• CONTRIBUTING.md/AGENTS.md: N/A
• Cross-platform: env parsing only; no platform-specific code
• Tool descriptions/schemas: N/A — no schema change