docs: clarify 0.2.0 acceptance evidence

docs/acceptance-0.2.0.md

@@ -116,8 +116,8 @@ Desired state is already installed.
 Production URI, config и state сохранены. Внутри `vpn-egress-gw` контрольный
 `find` по использованным диагностическим шаблонам не вернул результатов.
 
-Подтверждены clean installation и first apply, генерация config, runtime
-health, DNS, gateway E2E, idempotent no-op, E2E клиента за `br_vpn`, recovery
-после запуска сервиса и fail-closed защита от прямого WAN.
+Подтверждены clean-state first apply, генерация config, runtime health, DNS,
+gateway E2E, idempotent no-op, E2E клиента за `br_vpn`, recovery после запуска
+сервиса и fail-closed защита от прямого WAN.
 
 Итоговый статус: `PASS / PRODUCTION E2E VALIDATED`.

docs/troubleshooting.md

@@ -57,13 +57,14 @@ Backup и metadata рассогласованы или повреждены. А
 Проверить DNS, Gecko password, auth, SNI, certificate, UDP path и nftables.
 Успешный локальный healthcheck не заменяет forwarding E2E с `eth1`.
 
-## Ранее наблюдавшиеся «UFO»-отказы
+## Ранее наблюдавшийся transport failure на старом endpoint
 
-Прежние необъяснённые отказы, условно обозначавшиеся как «UFO», не оказались
-дефектом `vpn-egressctl 0.2.0`, renderer или sing-box 1.14.0. На том же gateway
-и с тем же клиентским стеком endpoint Aéza сначала прошёл независимый E2E
-официальным клиентом Hysteria 2.12.2, а затем полный production acceptance
-`vpn-egressctl`.
+Ранее наблюдавшиеся таймауты на старом server endpoint не оказались
+воспроизводимым дефектом `vpn-egressctl 0.2.0`, renderer или sing-box 1.14.0.
+Официальный клиент Hysteria 2.12.2 на том же gateway также не мог установить
+соединение с проблемным endpoint. После перехода на независимый endpoint тот же
+gateway и клиентский стек успешно прошли сначала direct Hysteria2 E2E, а затем
+полный production acceptance `vpn-egressctl`.
 
 Это не отменяет диагностику каждого нового сбоя, но позволяет не считать старый
 эпизод воспроизводимым дефектом control plane. При похожих симптомах сначала