telegram: send through the x-ui relay instead of straight at the API

Direct egress to api.telegram.org does not work from homesrv, so every
away-channel send timed out and the service_down nudge retried once a
minute forever. The sink already had a Proxy field wired to
http.Transport.Proxy; nothing had ever set it.

The relay is the x-ui socks inbound on the host, port 10808, addressed from
the container as the maven_default bridge gateway. That also needs a ufw
rule, because the bridge subnet is not otherwise allowed to reach a host
port and the SYN is dropped rather than refused. The rule is recorded in
the config next to the address, since the address alone is not enough to
reproduce this on another box.

Verified: five minutes after restart, zero send errors where there was
previously one per minute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TrVSBKe3RFDF4fGYKWYQnX

deploy/mavend.json

@@ -16,7 +16,17 @@
 
   "telegram": {
     "bot_token": "${TELEGRAM_BOT_TOKEN}",
-    "chat_id": "${TELEGRAM_CHAT_ID}"
+    "chat_id": "${TELEGRAM_CHAT_ID}",
+
+    "//proxy": [
+      "api.telegram.org is not reachable directly from this box, so every send",
+      "timed out. The relay is the x-ui socks inbound on the host, port 10808;",
+      "192.168.240.1 is the maven_default bridge gateway, which is how a",
+      "container addresses the host. mavend is on that network.",
+      "This needs a matching ufw rule or the container's SYN is dropped:",
+      "  ufw allow from 192.168.240.0/20 to any port 10808 proto tcp"
+    ],
+    "proxy": "socks5://192.168.240.1:10808"
   },
 
   "digest": {