Cap Telegram flood-wait sleep so long RetryAfter cannot hold the chat lock

bot.py

@@ -315,6 +315,12 @@ TELEGRAM_DOWNLOAD_MAX_BYTES = _env_number("TELEGRAM_DOWNLOAD_MAX_BYTES", 20 * 10
 TELEGRAM_GET_FILE_TIMEOUT = _env_number("TELEGRAM_GET_FILE_TIMEOUT", 15, min_value=1)
 # Cooldown после HTML-мусора от прокси вместо JSON: без него десятки вызовов/сек валят лавину WARNING (см. _tg_call).
 TELEGRAM_PROXY_COOLDOWN_SEC = _env_number("TELEGRAM_PROXY_COOLDOWN_SEC", 20, min_value=0)
+# Потолок одного сна по Retry-After в _tg_call: длинный flood-wait иначе держит
+# лок чата сверх бюджета маршрута (аудит 10.2026). Сам ретрай сохраняется.
+TELEGRAM_FLOOD_SLEEP_MAX_SEC = _env_number("TELEGRAM_FLOOD_SLEEP_MAX_SEC", 10, min_value=1)
+# TIKTOK_GROUP_REQUIRE_MENTION=1 — ссылки TikTok в группах без обращения к боту
+# только пишутся в фон, а не качаются (аудит H2, 10.2026). По умолчанию выключено.
+TIKTOK_GROUP_REQUIRE_MENTION = os.getenv("TIKTOK_GROUP_REQUIRE_MENTION", "0") == "1"
 # Лимит ожидания следующего куска для любого провайдера: зависший стрим иначе держит лок чата бесконечно.
 STREAM_CHUNK_TIMEOUT_SEC = _env_number("STREAM_CHUNK_TIMEOUT_SEC", 30, min_value=1)
 # ── Паттерн "живой печати" при стриминге (см. lumen_typing_pace.py) ──

docs/ENVIRONMENT.md

@@ -66,6 +66,7 @@ Before publishing, configure the same `LUMEN_PROXY_SECRET` on HF and every Deno
 | `TELEGRAM_MEDIA_TIMEOUT` | `25s` | Timeout for downloading media files from Telegram. |
 | `TELEGRAM_DOWNLOAD_MAX_BYTES` | `20971520` (20 MB) | Cap on a single Telegram download (Bot API doesn't serve bigger files via `getFile`); bigger files are refused before downloading with an honest user-facing message. |
 | `TELEGRAM_GET_FILE_TIMEOUT` | `15s` | Timeout for the `getFile` metadata call before a download. |
+| `TELEGRAM_FLOOD_SLEEP_MAX_SEC` | `10s` | Cap on a single `RetryAfter` sleep in Telegram calls, so a long flood-wait cannot hold the chat lock past the route budget (the retry itself is kept). |
 | `TTS_MAX_CHARS` | `800` | Size of one `/tts` synthesis chunk; up to `TTS_MAX_PARTS` (5) chunks are synthesized, so the accepted maximum is `TTS_MAX_CHARS × TTS_MAX_PARTS` (4000 by default). |
 | `TTS_SYNTH_TIMEOUT_SEC` | `60s` | Timeout for a single TTS synthesis call. Also passed into the SDK as `http_options.timeout`, so a hung provider cannot hold the chat lock. |
 | `TTS_TOTAL_BUDGET_SEC` | `240s` | Total deadline for all chunks of one multi-chunk TTS request; past it the text is cut and the user is told only the beginning was voiced. |
@@ -100,6 +101,7 @@ Before publishing, configure the same `LUMEN_PROXY_SECRET` on HF and every Deno
 | `TIKTOK_SLIDESHOW_MAX_BYTES` | `200 MB` | Total RAM cap for one slideshow post; slides past it are skipped (a typical post is under 50 MB). |
 | `TIKTOK_SLIDE_DOWNLOAD_CONCURRENCY` | `8` | Max slideshow slides downloaded in parallel; keeps one large post from hogging the shared HTTP connection pool. |
 | `TIKTOK_VIDEO_SLIDE_PROBE_CONCURRENCY` | `4` | Max concurrent `ffprobe`/`ffmpeg` processes when probing "live" video slides in a slideshow. |
+| `TIKTOK_GROUP_REQUIRE_MENTION` | `0` | Set to `1` so TikTok links in groups without addressing the bot are only recorded as background instead of downloaded. |
 
 ## Persistent storage
 

lumen_transport_calls.py

@@ -219,7 +219,10 @@ async def _tg_call(method: Any, *args: Any, call_timeout: float | None = None, r
                 break
             if attempt < retries:
                 # Флуд-контроль ждём по retry_after, остальное — коротким бэкоффом.
-                await asyncio.sleep(_tg_retry_after_sec(exc) or 0.5 * (attempt + 1))
+                # Сон ограничен капом: длинный retry_after иначе держит лок чата
+                # сверх бюджета маршрута (аудит 10.2026). Ретрай после капа остаётся.
+                wait = _tg_retry_after_sec(exc) or 0.5 * (attempt + 1)
+                await asyncio.sleep(min(wait, bot.TELEGRAM_FLOOD_SLEEP_MAX_SEC))
     if last_exc is not None and "message is not modified" in str(last_exc).lower():
         # "message is not modified" — валидный ответ API (семантический не-op), а не сбой: засчитываем успех, иначе повторные edit_text накручивали бы счётчик.
         bot._tg_proxy_breaker.note_success()
@@ -250,7 +253,7 @@ async def telegram_api_call(method: str, payload: dict, *, request_timeout: floa
             # См. _handle_proxy_failure — выключатель срабатывает по счётчику
             # подряд идущих сбоев (см. _TelegramProxyCircuitBreaker), а не на первый же сбой.
             await bot._handle_proxy_failure(f"вызове {method}")
-        # Цепочку не рвём (from exc): Sentry должен видеть первопричину, а не только обёртку.
+        # Цепочку сохраняем через from exc: Sentry должен видеть первопричину, а не только обёртку.
         raise RuntimeError(f"Network error in telegram_api_call for {method}: {exc_str}") from exc
     if not isinstance(data, dict) or not data.get("ok"):
         # Прокси round-trip'нул нормально и вернул валидный JSON — сам факт, что