fix(telegram): retry transient file download failures

[hcsum]

Problem

Incoming Telegram media is downloaded with node-fetch, outside the grammY Bot API retry middleware. A single transient failure therefore aborts the whole media group before it reaches OpenCode.

The observed failure was an ECONNRESET before TLS was established. The same path also lacked retries for HTTP 429/5xx responses and failures while reading the response body. In addition, a FetchError can contain the full Telegram file URL—including the bot token—and was logged unchanged.

Fix

• Run the complete file-download GET, including body consumption, through the shared retry helper.
• Retry 429 using Retry-After, transient 500/502/503/504 responses, and common transient network errors with exponential backoff, up to three retries.
• Keep broad network retries opt-in for this idempotent GET path; message-creation calls retain their duplicate-send protection.
• Prefer structured network codes and HTTP status fields over message-text fallback when classifying errors.
• Redact the bot token while preserving the error name, stack, and diagnostic fields such as code and status.

Tests

Regression coverage includes:

• pre-TLS connection reset;
• 429 with Retry-After;
• transient 502 response;
• interrupted response-body read;
• status-like numbers inside a failed request URL;
• bot-token redaction with diagnostic fields preserved.

The fault-proxy test helper now writes its call log before disconnecting the client, removing a CI-only race exposed while running the suite.

Verified with npm run lint, npm run typecheck, and npm test (161 files, 1857 tests). CI passes.

[grinev]

@hcsum thanks for contribution!