feat(telegram): honor config.yaml extra for inbound text batch delay

[Allenrcp]

Problem

Telegram already batches inbound text, but short bubbles are hard-capped at 180ms / 240ms (_TEXT_BATCH_FAST_DELAY_S / _TEXT_BATCH_SHORT_DELAY_S, PR #10388). Raising HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS cannot lift that cap (min(configured, 0.18)).

Real users send context as several bubbles (file, then instruction, then a follow-up). The agent starts on the first fragment.

WhatsApp already exposes platforms.whatsapp.extra.text_batch_delay_seconds and honors it. Telegram did not.

Approach

• Read platforms.telegram.extra.text_batch_delay_seconds / text_batch_split_delay_seconds / media_batch_delay_seconds (same keys as WhatsApp).
• When text_batch_delay_seconds extra is set, skip the 180ms/240ms adaptive caps so the configured quiet period is the quiet period.
• When extra is unset, keep the PR perf(gateway): reduce Telegram end-to-end response latency #10388 default (short replies still feel instant). No default-latency change.
• Env vars remain a fallback and still do not lift the short-message caps (behavior stays in config.yaml, not .env).
• Extract _text_batch_quiet_seconds so tests hit production logic.

Tests

• Existing adaptive-tier tests now call _text_batch_quiet_seconds.
• New: extra set → 3s delay on a 20-char bubble; split-threshold still uses split delay; _extra_has reads PlatformConfig.extra.
• Sabotage: disabling the extra branch makes the new test fail (0.18 == 3.0).
• uv run --extra dev pytest tests/gateway/test_telegram_text_batch_perf.py tests/gateway/test_telegram_text_batching.py → 12 passed.

Docs

website/docs/user-guide/messaging/telegram.md — Message batching section, mirrored on WhatsApp.

Risk

• Defaults unchanged if extra is unset.
• File-then-separate-text still use different queues (media vs text). Out of scope; caption-on-file remains the workaround for that mix.

Closes nothing (no open issue for this exact gap; #2434 already shipped the original batcher).

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

feat(telegram): honor config.yaml extra for inbound text batch delay

1. plugins/platforms/telegram/adapter.py — _text_batch_delay_from_config is only set from text_batch_delay_seconds, so a user who configures only text_batch_split_delay_seconds (leaving text_batch_delay_seconds unset) still gets the 180ms/240ms adaptive caps on short bubbles, even though the docs say "Setting the extra skips the 180ms/240ms caps". The doc statement is only true for the text_batch_delay_seconds extra. Either gate the cap-skip on "any batch extra present" or tighten the docs to say which key lifts the caps.
2. Split-delay extra validation: the extra branch clamps with max(self._text_batch_delay_seconds, 1.0) as the default but min_value=self._text_batch_delay_seconds. When _text_batch_delay_seconds is 0.0 (explicit extra), a configured text_batch_split_delay_seconds: 0.2 would clamp up to 0.2 — fine. But when the delay comes from the env path (_env_float_clamped with min 0.08) and the split extra is 0.05, _coerce_float_extra clamps it back up to the delay — consistent, but note that a split delay below the base delay is silently rewritten rather than rejected. Probably fine; just flagging the silent coercion.
3. _text_batch_quiet_seconds now reads self._text_batch_split_delay_seconds in the first branch without checking _text_batch_delay_from_config — correct, since split chunks should always use the longer delay. The refactor preserves the original tier order (split check first), so behavior for env-only configs is unchanged; the extracted function makes this easy to verify, which is good.
4. Minor: the new _extra_has helper does getattr(getattr(self, "config", None), "extra", None) — if config.extra is a dict subclass or a mapping that's not a plain dict, the isinstance(extra, dict) check rejects it. PlatformConfig.extra is a plain dict per the test, so this is only a note if other platform configs pass a different mapping type.