fix(telegram): use curl transport for explicit proxies - #982

Summary

• route Telegram Bot API POST requests through the existing curl transport when channels.telegram.accounts.<id>.proxy is configured
• retain the native HTTP transport for direct connections
• honor the per-request timeout on the proxied path

Problem

The live channel probe already uses curlPostWithProxy, but the Telegram runtime uses the native proxy client. On an OpenWrt MIPS32r2 device behind an explicit HTTP proxy, the probe and direct Bot API checks succeeded while every runtime request (deleteWebhook, command sync, and getUpdates) returned a non-2xx status. This caused the channel manager to mark Telegram unhealthy and restart it repeatedly.

Using the same curl proxy path as the live probe fixed polling and delivery on the physical device. Keeping the change conditional preserves the native HTTP path for installations without an explicit channel proxy.

Validation

• zig fmt --check src/channels/telegram_api.zig
• MIPS build: zig build -Doptimize=ReleaseSmall -Dtarget=mipsel-linux-musleabi -Dembedded_wasm3=false (7/7 steps)
• physical OpenWrt MIPS32r2 gateway: health stayed ok, Telegram polling had zero transport errors, outbound agent delivery succeeded, and a service restart recovered cleanly
• full local suite reached 7,370 passing / 9 skipped; two unrelated network-environment tests failed (credentialed curl helpers preserve resolve pinning and resolveConnectHost fails on unresolvable host)

No credentials, endpoints, or device-specific configuration are included.