Однопоточный long-polling воркер обрабатывал апдейты строго
последовательно, и ничто не мешало одному флудящему клиенту слать
поток сообщений: каждое зеркалировалось (copyMessage) в support-топик,
а групповой Telegram-лимит ~20 msg/min общий на ВСЕХ клиентов сразу —
превышение даёт 429 с ожиданием 30-60с, за которое воркер не может
обработать ни одного апдейта от кого-либо ещё.
Переиспользован app.core.ratelimit.SlidingWindowLimiter (тот же
примитив, что уже применён для веб-чата поддержки, app/api/v1/support.py) —
ключ здесь TELEGRAM chat_id отправителя, лимит заметно ниже группового
Telegram-порога (5 msg/60s). Сообщения сверх бюджета не зеркалируются
(и не пишутся в tg_support_messages — маршрутизировать ответ всё равно
нечего без topic_message_id), клиент получает явное уведомление о
недоставке РОВНО один раз за окно (второй лимитер с limit=1 на то же
окно) — молчать нельзя (клиент решит, что доставлено), но повторные
уведомления на каждое превышение сами стали бы источником флуда.
