WTEL-9275: Fix bot service marker chain

[vlad-marusyk-wt]

Проблема

Після мерджу PR fix/WTEL-9275/variables-marker-in-ws зʼявилася регресія: коли клієнт надсилає файл, що порушує політику збереження, через текстовий шлюз БЕЗ налаштованого custom file_policy_fail шаблону, виникає каскад проблем:

• WS-event з маркером не доходить до оператора (хоча мав)
• Усі наступні повідомлення від клієнта блокуються в real-time
• У БД накопичується багато порожніх system-messages з експоненціальним backoff (паттерн Telegram webhook retry)
• Включення custom-шаблону "проштовхує" всі накопичені повідомлення залпом

Причина

Функція sendSystemLevelMessage ітерує всіх учасників діалогу і в default: гілці намагається переслати наше empty-text сервісне повідомлення з маркером назад клієнту в Telegram через SendMessageToGateway. Telegram Bot API відмовляється приймати порожній текст і повертає помилку, через що:

1. Ітерація вилітає на першій же помилці (return 0, err) - до WS-публікації для оператора діло не доходить
2. Помилка каскадом доходить до Telegram webhook, який повертає HTTP 500
3. Telegram ретраїть webhook з backoff, кожен retry створює нову порожню запис в БД, нові повідомлення клієнта чергуються позаду failed update

Вирішення

У default: гілці sendSystemLevelMessage додано пропуск пересилки в external chat-провайдер, якщо повідомлення має порожній текст і це сервісний маркер від бота. Тоді ітерація доходить до websocket-учасника (оператора), маркер успішно публікується в WS, webhook повертає 200 OK, Telegram просуває offset і подальші повідомлення клієнта проходять без блокування.