[FIX] telegram: queue sends issued before the adapter is ready instead of dropping them

[MartinEbner]

Messages sent through send_message while the poll loop hasn't connected yet (or before a
chat is bound) are dropped silently. The window is real: _connected only turns true once the
first getUpdates long-poll returns — up to poll_timeout seconds after start — so the first
thing an agent says after launch can vanish. We observed exactly this on a live instance
running the #240 logging: the agent's post-restart status message (106 chars, 15 s after boot)
was skipped — [SEND_SKIP] connected=False bound=True — while the agent's history recorded it
as sent. In auto-bind setups the loss is broader: everything sent before the first user DM is gone.

This PR queues unready sends and flushes them once the adapter is ready:

... | INFO     | telegram | [SEND_QUEUE] queued chars=106 (1 pending)
... | INFO     | telegram | [SEND_FLUSH] delivering queued message (0 left)
... | WARNING  | telegram | [SEND_QUEUE] full (50): dropped oldest queued message
... | WARNING  | telegram | [SEND_FLUSH] delivery failed, stopping drain (2 still queued)

Design notes:

• Bounded queue (50 messages; oldest dropped with a warning) — a pre-connect flood can't grow
  memory silently. Count-based bound; recency wins over stale boot messages.
• The flush runs from the poll loop after update processing, so a chat auto-bound in that very
  iteration is served immediately; the poll thread uses a non-blocking lock acquire so
  getUpdates never stalls behind a drain another thread is running. (When the poll thread
  drains itself, sends are inline — same as the existing auth confirmation on main.)
• Ordering is chronological end-to-end: a new ready send flushes the queue first, and if a
  failed drain left messages behind, it joins the queue instead of overtaking them.
• If a queued delivery fails mid-drain, the drain stops: the failed message is dropped
  (matching direct-send semantics today, and avoiding a poison message pinning the queue head)
  and the rest stays queued for the next poll-cycle flush — a rate-limit burst can't burn the
  whole queue in one failing drain.
• The queue intentionally survives stop_telegram/start_telegram, so an in-process reconnect
  loses nothing. Corollary (accepted): in auto-bind, messages queued before a rebind deliver to
  the newly bound chat — the same trust model as auto-bind itself.
• The chunked delivery path is unchanged — extracted into _deliver(), byte-identical apart
  from returning delivery success.

Tests: Autotests/unit/test_telegram_queue_until_connected.py — 8 in-process unit tests
(module loaded by file path, _api_call stubbed; no container, network, or token), wired into
Autotests/run_mandatory: queued-not-dropped (disconnected, and connected-but-unbound),
in-order flush, ready-send-flushes-first, no overtaking after a failed drain, bounded drop,
drain stop on delivery failure, drain stop on mid-flush disconnect. The poll-loop trigger and
auth-bound enqueue paths are not unit-tested (driving _poll_loop needs a live thread — scope
cut).

Run: pytest Autotests/unit/test_telegram_queue_until_connected.py

Possible follow-ups (not in this PR to keep it minimal): a bounded retry for the failed
head-of-line message with 429 retry_after backoff (would pair with #18, which proposes the
same for LLM-provider calls); a byte-size cap alongside the count bound.

Relation to #240 (send-status logging / chunk hardening): complementary — #240 made these drops
visible, this PR removes them; the queueing supersedes #240's [SEND_SKIP] log-and-drop in the
unready branch. Both touch send_message, so whichever lands second gets a mechanical rebase
(#240's per-chunk ok/fail counters map onto _deliver's success return as fails == 0).
Suggested order: #240 first (older, smaller), this second.