fix: маршруты, медиа и Worker; Android APK и статический ARM64 CLI (#60)

* fix: address routing, media, worker and platform issues

* ci: use available Android tools and verify Windows CLI artifact

* fix(gui): return a result from asynchronous stop command

* test(android): verify installed APK and proxy lifecycle on emulator

* fix(media): use native MTProto for CDN203 and retain recent diagnostics

* Fix owned WebSocket split after transport boxing

* Clarify CDN transport and connection status guarantees

* Recognize accessible Android power button labels

* chore(release): prepare 2.0.0-beta.15 with verified draft publication

---------

Co-authored-by: babin <Thartewerner536e@engineer.com>

docs/ARCHITECTURE_V2.md

@@ -201,22 +201,38 @@ Ping приходит в читающую половину, а отвечает
 
 1. сохранённый успешный маршрут;
 2. точный Telegram IP с `kwsN` или `kwsN-1` в TLS SNI и WebSocket Host;
-3. дополнительный Telegram IP, если он определён;
-4. системный DNS;
-5. явно настроенный пользователем Cloudflare Worker.
+3. явно настроенный пользователем Cloudflare Worker;
+4. дополнительные Telegram IP и варианты хоста;
+5. системный DNS (кроме CDN DC203).
 
-Поддерживаются DC1–5 и media/CDN DC203. DC203 использует WebSocket-host DC2,
-но подключается к собственному IP.
+Поддерживаются DC1–5 и CDN DC203. Для DC203 первым используется обычный MTProto
+TCP к закреплённому `91.105.192.100:443`; этот сервер может принимать MTProto,
+не принимая TLS/WebSocket. Резерв через Worker соединяется с тем же IP.
+WebSocket-попытки также сохраняют закреплённый адрес. DNS fallback на DC2 для DC203 запрещён:
+успешный WebSocket handshake с другим DC не доставляет CDN-запрос в нужный
+датацентр. Worker также получает именно IP DC203.
 
 После ошибки маршрут получает exponential cooldown от 30 секунд до 30 минут.
 Успешный маршрут становится первым для следующего соединения того же DC и
-типа трафика.
+типа трафика. Попытки запускаются с интервалом 250 мс, не больше трёх
+одновременно на соединение; остальные отменяются после первого успеха.
+Если все маршруты на паузе, возвращается причина и время до повторной
+попытки. Новое подключение клиента не обходит cooldown. Ошибка upstream
+после handshake также снимает предпочтение маршрута и добавляет cooldown.
 
 ## TLS policy
 
 Проверка сертификатов и hostname никогда не отключается. При подключении к
 заданному Telegram IP TCP destination отделён от URI host: TLS продолжает
-проверять сертификат настоящего `kws*.web.telegram.org`.
+проверять сертификат настоящего `kws*.web.telegram.org`. Используется rustls
+с провайдером ring и встроенными WebPKI roots; системный OpenSSL для ядра
+и CLI не нужен. Собственные корневые сертификаты ОС автоматически не
+подхватываются. Тесты проверяют доверенный сертификат, SNI, неверное имя
+хоста и недоверенного издателя.
+
+Это относится к TLS-маршрутам. Прямой CDN TCP — отдельный транспорт MTProto,
+а не TLS с отключённой проверкой. Он доступен только для точного назначения
+DC203. Для произвольных адресов такой обход политики не добавляется.
 
 Cloudflare Worker принимается только как пользовательская настройка. TGLock
 не загружает и не скрывает публичные списки чужих доменов.
@@ -229,9 +245,11 @@ Worker должен принимать WebSocket на:
 /apiws?dst=<telegram-ip>&dc=<dc-id>
 ```
 
-и проксировать бинарные frames в TCP `<telegram-ip>:443`. Рекомендуется
-добавить собственную авторизацию до стабильного релиза; поэтому Worker
-остаётся расширенной опцией alpha-версии.
+и проксировать бинарные frames в TCP `<telegram-ip>:443`. Ответ 101 отправляется
+после открытия upstream TCP; таймаут/отказ — HTTP 504/502. Список назначений
+фиксирован, текстовые сообщения отклоняются. Очередь входящих записей ограничена
+1 МиБ и 256 сообщениями. Авторизация токеном требует собственного клиента:
+штатный TGLock токен Worker пока не передаёт.
 
 Запись в сокет Telegram обязана быть последовательной: следующий чанк уходит
 после того, как записан предыдущий, и только когда писатель к этому готов