chore(tests): подтвердить цельную доставку очереди Telegram

docs/ux-ui-progress.md

@@ -1,6 +1,6 @@
 # UX/UI: журнал реализации
 
-Актуальное продолжение 2026-10-13: завершён200 — baseline lock-loss crash воспроизведён, исправленный collector survives/aborts stale run/recovery passed.71 owned SQL + concurrency/57603ms,1044 compiled matched, live traffic API/UI2 passed. Runtime backend ux-lock200/frontend ux-portal199. Следующий201 — цельный Telegram live с расширенной диагностикой и ограниченным бюджетом3 сообщений.12.5 открыта.
+Актуальное продолжение 2026-10-13: завершён201 — цельный real Telegram outbox/dedupe/two senders/unknown/no-auto-repeat/manual acknowledged retry passed в одной own DB; пользователь подтвердил1×№1+2×№2.200 collector crash/observed lock-loss fixed/deployed. Backend ux-lock200/frontend ux-portal199/Portal1.3.1. Следующий202 — reader API аудит секретов в административных интеграциях.12.5 открыта.
 
 Общий план: [UX/UI по этапам и пятичасовым окнам](ux-ui-plan.md). План задаёт объём, этот журнал фиксирует выполненные блоки и ограничения. Записи расположены от новых к старым; подробная история этапа12 также сохранена в [ux-ui-stage-12.md](ux-ui-stage-12.md).
 
@@ -38,6 +38,16 @@
 | 11Б | Оповещения, сбор данных, интеграции, релизы и настройки | Завершён в границах локальной приёмки 2026-10-03; ограничения и evidence в11Б.7 |
 | 12 | Итоговая доступность, адаптивность, производительность и регрессия | Локальная приёмка завершена в границах12.3.83; внешняя12.5 в работе, выполненные блоки1–196 и ограничения ниже. Runtime backend/frontend ux-peak196. |
 
+## 12.5.201 — цельный живой сценарий очереди Telegram (2026-10-13)
+
+Обновлён acceptance driver: ограниченный TEST label, request-start counters, safe HTTP status/accepted trace, dispatch outcome и финальная строка очереди; Telegram send pacing1500ms, отрицательные ответы provider не искажаются assertion в unknown. Драйвер не входит вtest:all, явный own DB/chat/duplicate-risk ACK обязательны, число live sends ограничено3 (resume1). Изменение только приёмочного инструмента; продуктовая очередь не менялась.
+
+Actual production compiled backend ux-lock200, ограниченная PostgreSQL own роль и real Portal JWT. В одном непрерывном прогоне/одной БД: duplicate dedupeKey → одна запись; два независимых sender процесса → один provider send и одна sent/history. Telegram accepted№2, receipt intentionally suppressed → unknown; повторная автоматическая диспетчеризация не отправляет. Reader retry403, missing acknowledgement400, admin version0→1 pending200, stale retry409. После подтверждённого ручного retry Telegram accepted, sent1/failed0/held0, итог две sent строки/две history. Provider принял три сообщения TEST201(IDs6/7/8); пользователь подтвердил одно№1 и два№2.
+
+Own DB/role/container и Portal reader user удалены, отдельный private bot file удалён; рабочие настройки приложения сохранены. Нативные CHR и runtime images не менялись, дополнительных отправок вне бюджета не было. Полный успешный201 теперь дополняет partial/failed197 и отдельный resume197; исходный failed evidence сохраняется. Точная причина первого сбоя197 не установлена: pacing/новая диагностика не выдаются за доказательство его причины или исправление продуктового дефекта. Controlled receipt loss не является физическим WAN timeout/доказательством exactly-once на стороне Telegram.
+
+Протокол: [цельный live тест и подтверждение пользователя](ux-ui/acceptance/telegram201-live-2026-10-13.json). Следующий202 — reader API аудит секретов административных интеграций; широкие публичные IPv6/clientOS/independentWAN/scale/external jobs остаются в матрице.12.5 открыта.
+
 ## 12.5.200 — восстановление коллектора после падения и потери блокировки (2026-10-13)
 
 В отдельной own DB/ограниченной роли на Linux два сценария действительного сбоя: SIGKILL дочернего коллектора при удержанном ответе локального RouterOS fixture и pg_terminate_backend только собственного lock PID, выбранного по точным datname/usename/key8723105. Production PID/CHR не затрагивались. Старый production compiled ux-peak196 воспроизвёл Unhandled error event и nonzero exit при потере session-lock connection. После SIGKILL PostgreSQL освободил advisory lock, новый процесс собрал первую волну. Baseline не выдаётся за passed исправление.