[FIX] telegram: don't abort remaining chunks when one chunk fails; greppable send-status log lines

[MartinEbner]

Two small robustness fixes to the Telegram send path, no behavior change on the happy path. Rebased onto current main; the new log lines go through the structured logger (src.logger) introduced in #226.

1. A failed chunk no longer aborts the remaining chunks. send_message splits
long messages at 3900 chars, but any chunk failure returned out of the loop, so
the tail of a long multi-chunk message was silently dropped. Now the failed chunk
is logged (logger.exception, so the traceback is kept), the sender pauses 1s
(the most likely chunk failure is a rate limit — don't hammer the API), and the
remaining chunks are still attempted — partial delivery with a diagnosable log
beats silently losing the rest. (Related community pain: the long-running
truncated/multi-send-failure reports in the ASI Alliance channel.)

2. Greppable delivery-status log lines. Every send now ends with a summary,
and skipped/failed sends leave a trace:

... | INFO     | telegram | [SEND_OK] chunks=2 chars=5100
... | ERROR    | telegram | [SEND_FAIL] chunk=1/3 err=<exception>       <- per failed chunk, with traceback
... | WARNING  | telegram | [SEND_PARTIAL] ok=2 fail=1 chars=11700
... | ERROR    | telegram | [SEND_FAIL] ok=0 fail=3 chars=11700         <- every chunk failed
... | WARNING  | telegram | [SEND_SKIP] connected=False bound=True chars=42   <- previously dropped with no trace

This makes "did my message actually go out?" answerable from the log — useful
both for operators and for the agent-side self-verification patterns the
community has been building (send-then-verify).

Tests: Autotests/unit/test_telegram_send_chunking.py — in-process unit
tests following the mock_websocket/test_wschat_unit.py pattern (module loaded
by file path, _api_call stubbed, caplog assertions; no container, network,
or token needed), wired into Autotests/run_mandatory so CI executes them:

• single-chunk success logs [SEND_OK]
• 3900-char chunk boundaries preserved
• a mid-message chunk failure still attempts the remaining chunks (after a 1s pause) and logs [SEND_FAIL] + [SEND_PARTIAL]
• every chunk failing logs a [SEND_FAIL] ok=0 summary instead of claiming partial delivery
• unbound/disconnected sends nothing and logs [SEND_SKIP]

Run: pytest Autotests/unit/test_telegram_send_chunking.py

Possible follow-up (not in this PR to keep it minimal): a single retry per failed
chunk (honoring 429 retry_after) before counting it as failed — the send-path
analogue of what #18 proposes for LLM-provider 429s.