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

docs/ux-ui-progress.md

@@ -1,6 +1,6 @@
 # UX/UI: журнал реализации
 
-Актуальное продолжение 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 открыта.
+Актуальное продолжение 2026-10-13: блок198 — actual expired JWT401, reissue role changes, logout boundary и live expired recovery ПК/телефон приняты. Первый внешний return_to и browser logout passed; остальные два return_to ограничены подтверждённым429 Portal. Runtime ux-peak196. Следующий199 — сохранить исходный раздел/параметры после SSO;12.5 открыта.
 
 Общий план: [UX/UI по этапам и пятичасовым окнам](ux-ui-plan.md). План задаёт объём, этот журнал фиксирует выполненные блоки и ограничения. Записи расположены от новых к старым; подробная история этапа12 также сохранена в [ux-ui-stage-12.md](ux-ui-stage-12.md).
 
@@ -38,6 +38,20 @@
 | 11Б | Оповещения, сбор данных, интеграции, релизы и настройки | Завершён в границах локальной приёмки 2026-10-03; ограничения и evidence в11Б.7 |
 | 12 | Итоговая доступность, адаптивность, производительность и регрессия | Локальная приёмка завершена в границах12.3.83; внешняя12.5 в работе, выполненные блоки1–196 и ограничения ниже. Runtime backend/frontend ux-peak196. |
 
+## 12.5.198 — срок действия Portal JWT, права и выход (2026-10-13)
+
+Использован настоящий JWT, выданный Portal в195 и естественно истёкший к проверке: MM GET servers401, Portal me401 и reissue401. Токен не редактировался и TTL не менялся. На собственном временном reader через документированный PUT /api/v1/admin/users/:id/access удалён доступmm: прежний JWT по-прежнему200 доexp, reissue200 выдаёт текущие claims и новый MM JWT403. Возвращённый доступ и новый reissue восстановили200. Первый неверно адресованный PATCH в диагностическом драйвере был исправлен на PUT/access; изменение source продукта не требовалось. User fixture удалён204.
+
+Logout200 очищает refresh cookie(Max-Age0), но ранее выданный bearer MM JWT остаётся200 и Portal reissue с ним также200 доexp. Это подтверждённая граница offlineJWT и Portal1.3.1: cookie/session logout не означает немедленный отзыв access token. Свежие JWT/credentials в Git не сохранялись.
+
+Live UI1440/320 с настоящим expired JWT: MM очистил mmapp_token, направил на Portal, реальный login/callback восстановил приложение, fragment удалён, overflow/page errors нет. Однако callback открыл /dashboard вместо исходного /servers: контекст не сохранён, следующий199 исправляет это. Внешний https://outside.invalid/auth/callback не вызвал попытки навигации после login; Portal остался на /admin. Browser /logout очистил token storage и показал login. Защитный browser route только блокировал возможную недоверенную навигацию, ответы API не подменял.
+
+Оставшиеся return_to на другой localhost port и похожий hostname не приняты: серия диагностических входов достигла rate limit Portal. HTTP GET / и /api/v1/auth/config подтвердили429 с Retry-After18/17s; это не объявлено ошибкой защиты return_to. Промежуточные успехи сохранены отдельно, полный UI прогон не claimed. Повторять только эти оставшиеся случаи после cooldown, без нового полного цикла. Source/runtime/ReUI не менялись.
+
+Протоколы: [actual lifecycle API](ux-ui/acceptance/portal198-lifecycle-2026-10-13.json), [live UI и границы429](ux-ui/acceptance/portal198-live-ui-2026-10-13.json).
+
+Следующий199: восстановить исходный same-origin раздел и query после SSO с проверкой permissions и запретом внешних/auth callback redirect. Затем профильные E2E/deploy и два оставшихся Portal return_to.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.