chore(tests): проверить доставку Telegram и сохранить границы повтора

docs/ux-ui-remaining-acceptance.md

@@ -1,8 +1,8 @@
 # Оставшаяся внешняя приёмка — 2026-10-13
 
-Актуальное продолжение 2026-10-13: завершены191–196. Runtime backend/frontend ux-peak196, Portal1.3.1 healthy, AUTH_REQUIRED=true; reader password redacted вlist/detail, writer/admin сохранены, runtime Portal links исправлены. SQL roles3×2 endpoints/10996ms, E2E41/1.4m, live reader/admin UI4 passed. Telegram базовая доставка подтверждена пользователем. Следующий197 — real Telegram outbox/dedupe/multiple senders/unknown hold/manual retry в собственной временной БД.12.5 открыта.
+Актуальное продолжение 2026-10-13: блок197 — Telegram live dedupe/two senders/unknown hold и отдельный explicit retry приняты, пользователь подтвердил одно№1/два№2. Первый полный live прогон не прошёл immediate retry; причина не установлена, цельный live сценарий остаётся открытым. Runtime backend/frontend ux-peak196, Portal1.3.1 healthy, AUTH_REQUIRED=true. Следующий198 — Portal expiry/logout/reissue и return_to;12.5 открыта.
 
-Это актуальная матрица после 12.5.196. Исторические записи сохраняют версии и ограничения на момент выполнения; поздние проверки ниже уточняют их. Этап 12.5 открыт. Успех в двух CHR и одном backend не означает приёмку всех конфигураций, интеграций или полной регрессии.
+Это актуальная матрица после 12.5.197. Исторические записи сохраняют версии и ограничения на момент выполнения; поздние проверки ниже уточняют их. Этап 12.5 открыт. Успех в двух CHR и одном backend не означает приёмку всех конфигураций, интеграций или полной регрессии.
 
 Стенд: Debian13/Compose, PostgreSQL18.6, два CHR RouterOS7.24.5. Backend/frontend `ux-peak196`; production lab с195 использует AUTH_REQUIRED=true и Portal1.3.1. Подписанные JWT/RBAC проверялись в изолированных процессах. Все собственные объекты112 удалены, исходные13 коллекций×2 (включая logging/certificates/files/routes) проверены; пароли не менялись.
 
@@ -26,7 +26,7 @@
 
 ## Следующая последовательность — 2026-10-13
 
-1. **197 — реальный Telegram outbox:** dedupe/two senders/unknown hold/explicit retry на собственной БД и тестовом чате.195–196 базовый SSO/Telegram transport, masked server DTO и runtime links приняты. Затем Portal expiry/revoke boundary и crash/lock-loss.
+1. **198 — Portal expiry/logout/reissue и return_to:** базовый SSO, reader privacy и Telegram доставки приняты с границами197. После — диагностика цельного Telegram сценария/crash/lock-loss.
 2. **Профильный контроль:** для новых изменений выполнять затронутые SQL/API/UI проверки. Общая регрессия192 выполнена; не повторять её без изменений общей основы или нового основания.
 3. **Внешние зависимости:** Portal issuer/login/revoke, Telegram bot/chat/разрешённое сообщение, клиентские ОС, независимые WAN/public IPv6 и scale/multi-instance — отдельные группы по таблице выше. Ограничения текущего стенда не превращать в обещание приёмки всех конфигураций.
 
@@ -1304,3 +1304,15 @@ Production backend/frontend ux-peak196 развёрнуты.466 backend+525 fron
 | [ReUI App Shell12](https://reui.io/preview/base/app-shell-12?ref=mcp) | Runtime issuer/Portal → меню приложений → тот же Portal; reader → masked DTO + blocked edit, writer → existing editor |
 
 Следующий197: реальная доставка из outbox через собственную временную БД, dedupe/two senders, controlled lost receipt после реального Telegram acceptance, no automatic repeat, explicit acknowledged retry/stale version/RBAC. Планируется3 помеченных test messages, включая намеренный повтор№2; не превращать controlled receipt suppression в физическую WAN/lost-ACK приёмку. Portal JWT revocation доexp, настоящее expiry/refresh/client OS и crash/lock-loss остаются отдельными границами.12.5 открыта.
+
+## 12.5.197 — доставка Telegram и управляемый повтор (2026-10-13)
+
+Production compiled outbox проверен в собственной временной PostgreSQL БД и ограниченной роли, с реальными JWT Portal и тестовым Telegram bot/chat. Первый live прогон: enqueue с одинаковым dedupeKey сохранил одну запись; два независимых Node sender процесса выполнили одну отправку, одна запись sent и одна history. Telegram принял№2, затем драйвер намеренно подавил ответ: статус unknown, следующая автоматическая диспетчеризация не отправила сообщение повторно. Это контролируемая имитация потерянного ответа, не физический обрыв WAN.
+
+Reader retry403, отсутствие acknowledgedDuplicateRisk400, admin expectedVersion0→1 с подтверждением риска200, повтор старой версии409. Однако завершающий assert первого полного live прогона sent=1 не прошёл; outcome тогда не был записан. Причина не установлена. Исходный failed протокол сохранён, цельный непрерывный live сценарий не объявляется пройденным. Для локализации полный сценарий с реальной БД/Portal JWT и симулированным Telegram ответом прошёл без сетевых отправок. Далее только оставшаяся ручная отправка проверена на новой собственной unknown fixture: Telegram accepted, status sent, resolutionVersion1, history одна. Это отдельный успешный live тест, не продолжение прежней БД.
+
+Всего реально приняты3 сообщения: одно TEST197№1 и два одинаковых TEST197№2, последние являются намеренным повтором. Пользователь подтвердил именно это количество. Три own DB/role/container и собственные Portal reader users удалены; временный private bot file на сервере удалён. Рабочие настройки Telegram приложения сохранены для следующих пользовательских проверок. Пароли/конфигурация CHR не менялись, runtime остаётся ux-peak196. Драйвер не входит вtest:all, требует own DB, явный чат и подтверждение риска, имеет отдельный resume режим. Диагностика завершающей отправки теперь сохраняет outcome/статус; отрицательный provider response не превращается assert в искусственный unknown, счётчик учитывает начало request.
+
+Протоколы: [первый partial/failed live](ux-ui/acceptance/telegram197-partial-2026-10-13.json), [полный SQL с simulated provider](ux-ui/acceptance/telegram197-dry-result-2026-10-13.json), [отдельный live retry](ux-ui/acceptance/telegram197-resume-result-2026-10-13.json), [итог и ограничения](ux-ui/acceptance/telegram197-summary-2026-10-13.json).
+
+Следующий198: настоящий expiry/logout/reissue Portal и безопасный return_to. Первый непрерывный Telegram live сценарий остаётся диагностической границей; повторять его только при достаточной диагностике и основании, а не отправлять дополнительные дубли ради зелёного счётчика.12.5 открыта.