@torrent-tv/proxy 2.87.10 → 2.87.11

package/research/handover-2026-09-13.md

@@ -1,209 +1,209 @@
-# Передача: клин доставки, стенд и werift — 2026-09-13
-
-Написано для того, кто продолжит. Всё, что ниже, либо прочитано из журналов и
-кода, либо помечено как непроверенное.
-
-## 1. Что установила сессия 2026-09-12 (прокси 2.83.5)
-
-Показ встал на **521,2 с фильма** и не возобновился. Причина — клин доставки,
-и он снят на проводе с обеих сторон. Разбор:
-`research/delivery-wedge-on-the-wire-2026-09-12.md`.
-
-Цепочка, каждое звено с числом из журнала:
-
-1. 21:50:39.658 — последнее, что браузер получил. Его счётчик канала
-   `proxy=12112msg/479898176B` не сдвинулся больше ни разу;
-2. прокси продолжал отдавать: `sent=485243979 → 485263428`, очереди
-   `queued[proxy:0B proxy-control:0B proxy-fast:0B]`, `rtt=24ms`,
-   `pc=connected ice=completed`. Обратное направление работало весь клин;
-3. через ассоциацию прошло **485 МБ**. Прежние эпизоды: 783, 813, 825, 2294 МБ.
-   Порога по объёму нет;
-4. обрыв пойман посреди отдачи одного куска: `bytes=10657210 sendMs=360
-   bufferedAtEnd=0` — usrsctp принял всё, очередь пуста; на проводе за
-   следующие три секунды ушло 6 727 961 байт (≈63 %), и в середине четвёртой —
-   ноль, без ретрансмиссий и без утоньшения подтверждений.
-
-**Лечение было измерено и выброшено.** Браузер поднял вторую ассоциацию к тому
-же пиру, прокачал `GET /api/delivery-sink?bytes=4194304` за 140 мс, записал
-`the fault is held in the wedged association` — и **закрыл её через 0,45 с**.
-Показ остался на мёртвой.
-
-**Почему зритель сидит навсегда, а не минуту:** лестница пересоединения не
-запускается. В клиентском журнале нет ни `transport lost`, ни `reconnect
-attempt`, потому что заклинивший канал остаётся `state=connected
-ice=connected`, и объявлять его потерянным нечему. В тот же вечер в 20:03 на
-ЗАКРЫТОМ канале та же лестница отработала штатно.
-
-## 2. Две поправки к роадмапу, сделанные чтением кода
-
-1. **`waitForBufferDrain` УЖЕ починен** (`services/data-channel-handler.js:1199`,
-   выпущено в 2.80.6): он ждёт нижней отметки с опросом каждые 50 мс,
-   постоянная `DC_BUFFER_DRAIN_TIMEOUT_MS` удалена. Запись в роадмапе
-   («fails open», 2026-09-06) устарела.
-2. **И он всё равно не защищает.** В поле 2026-09-12 `bufferedAtEnd=0` и
-   `drainMs=0` на каждой строке: наша очередь пуста, потому что libdatachannel
-   отдал байты в usrsctp, а держит их usrsctp. `bufferedAmount()` слеп к этому
-   по построению — прокси отдал 10,6 МБ в тишину и не узнал.
-
-**Что на месте этого предложено и НЕ построено:** backpressure по тому, что
-зритель ПОДТВЕРДИЛ. Браузер уже сообщает счётчики каждого канала
-(`proxy=12112msg/479898176B` в строке `[dc-far]`, раз в 500 мс). Отправка
-сверяется с ними, а не только с `bufferedAmount()`. Порог не выбирать — вывести
-из того, сколько байт эта связь держит в полёте при здоровой работе.
-
-## 3. Обновление зависимости — проверено, не лечит
-
-Пин `^0.32.0`, в npm **0.33.4**. Внутри libdatachannel 0.24.2 → 0.24.5.
-Подмодуль usrsctp сверен по четырём тегам (v0.24.2, .3, .4, .5):
-`fec583d54493f879d2ae44a743423bf8a04371ab` во всех. **От клина не лечит.**
-Запись роадмапа «upstream fix waiting нет» была верна на 26.08; теперь
-перепроверена и по-прежнему верна по существу, но libdatachannel ушёл вперёд
-на три версии (там исправление прерывистых отказов DTLS-рукопожатия).
-
-## 4. werift — исследовано, читая сам пакет
-
-werift 0.24.4, MIT, обновлён 2026-08-10, один автор. 4,2 МБ, 9 зависимостей.
-`ice/`, `dtls/`, `sctp/`, `rtp/`, `webrtc/` — полная реализация на TypeScript.
-
-**За:**
-1. usrsctp исчезает целиком, а с ним и подозреваемый;
-2. ни одной нативной зависимости (`@noble/curves`, `tweetnacl`,
-   `@peculiar/x509` — чистый JS). Ни prebuilt, ни musl/aarch64, ни сборки в
-   дополнении. Для проекта с одним форком нативного модуля и девятью смертями
-   процесса это существенно;
-3. `bufferedAmount`, `bufferedAmountLow`, `bufferedAmountLowThreshold` есть —
-   наш backpressure переносится.
-
-**Против:**
-1. **Мультиплексирования одного UDP-порта нет.** `lib/common/src/transport.js:130`
-   создаёт `dgram.createSocket` на соединение; `icePortRange` — диапазон, а не
-   общий сокет. У нас `IceUdpMuxListener` держит один порт 9090 на все сессии,
-   и ровно он замаплен UPnP — шаг 3 удалённого доступа (2.9.18). На werift
-   каждая сессия берёт свой порт, которого в маппинге нет;
-2. **Цена в процессоре не измерена и может быть запретительной.**
-   `lib/sctp/src/sctp.js:16` — `USERDATA_MAX_LENGTH = 1200`. Сообщение в 65 КБ
-   режется на 55 SCTP-кусков, каждый собирается в JS, CRC32c через
-   `Buffer.concat` на пакет (`chunk.js:763`), поверх — DTLS-шифрование на JS.
-   При 8 Мбит/с ≈830 пакетов/с; на измеренных 24.08 пиках 150-330 Мбит/с —
-   за 30 000/с. На CM4, который кодирует 1080p на 1,96x.
-
-**Вывод:** werift снимает подозреваемого и платит сломанным единым портом и
-неизвестной производительностью. Назвать его решением до замера нельзя.
-Замер дешёвый: поднять werift-приёмник, прокачать гигабайт, сравнить загрузку
-процессора с сегодняшней.
-
-## 5. Стенд — построен наполовину, упёрся в выбор прокси
-
-Цель: измерить, ЗАВИСИТ ЛИ КЛИН ОТ РАЗМЕРА ПОРЦИИ. Это гейт на всё остальное,
-и он не снят ни разу — стенд 26.08 прокачал 1,0 ГБ без отказов, но его
-приёмник был libdatachannel, а нужен dcSCTP браузера.
-
-**Что работает:** `chrome-devtools` MCP подключён к Chrome 155 на 9222
-(`list_pages` отвечает). Локальный прокси поднимается и регистрируется:
-
-```
-node bin/cli.js --server-url https://webauth.courses --port 9091 \
-  --delivery-sink --name wedge-stand --log-file <path>
-```
-
-**Что мешает:** браузер его не выбирает. Дважды подряд, включая после
-перезагрузки страницы:
-
-```
-selectedId: f3013ad3 (полевой, хост дополнения)
-candidates: wedge-stand score=0.6075, proxy-f3013ad3 score=0.4466
-```
-
-Стенд имеет ЛУЧШИЙ счёт и не выбран. Отличие одно: `reachable: false` —
-сервер дозванивается снаружи и до машины разработчика не достаёт. Значит
-нагрузка пошла бы на рабочий узел, чего делать нельзя.
-
-**Два выхода, решение за пользователем:** сделать стенд достижимым (проброс
-порта) или добавить способ назначить прокси явно (правка продукта ради
-стенда).
-
-**Оговорка, которую надо держать при любом прогоне:** клин наступал при 485,
-783, 813, 825 и 2294 МБ — разброс впятеро. Одна прогонка на значение не
-докажет ничего; нужно по нескольку, и это часы прокачки. Если разброс внутри
-одного размера порции останется таким же, честный ответ — «не установлено», а
-не число.
-
-**Механика автономного прогона, продуманная и не построенная:** фоновый
-процесс через `run_in_background`; цикл в странице ставится ОДНИМ вызовом
-`evaluate_script` и дальше живёт сам; результат выходит через `client-logger`
-на сервер, а не через канал данных, — этот путь HTTP и переживает клин, чего
-сегодня не хватило (пункт 85: браузер замолчал ровно на клине).
-
-## 6. Что делать дальше, по порядку
-
-1. снять препятствие со стендом и взять замер размера порции — это гейт;
-2. backpressure по подтверждённому зрителем (§2), целиком наш код;
-3. замер werift на процессоре, если §1 не даст ответа;
-4. сообщить наверх: у нас есть то, чего нет ни у кого — два захвата с обеих
-   сторон и доказательство, что вторая ассоциация к тому же пиру работает в ту
-   же секунду. Ни в libdatachannel, ни в usrsctp вопрос не открыт.
-
-**Чего делать НЕ надо:** прямой HTTPS (шаги 6-7) как ответ на этот клин.
-Сказано пользователем 2026-09-12: это не решение проблемы.
-
-## 7. Что осталось незакрытым от прошлых сессий и всплыло сегодня
-
-1. ложное срабатывание 21:13:34 при 76 МБ прокачанных — 180 с захвата и файлы
-   кольца на показ, который шёл дальше ещё 37 минут;
-2. `--delivery-sink` включён на полевом прокси. Он отдаёт ответ любого размера
-   и существует только для стенда.
-
-## 8. СОСТОЯНИЕ НА КОНЕЦ 2026-09-12: дополнение ОСТАНОВЛЕНО, на его месте стенд
-
-**Смотреть нельзя, пока это не свёрнуто.** Дополнение остановлено намеренно
-(`ha apps stop b34a1737_torrent_tv_proxy`), и его место на порту 9090 занял
-контейнер `ttv-wedge-stand`, запущенный из того же образа
-(`b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`) с пропатченными
-`services/data-channel-handler.js` и `bin/cli.js`.
-
-**Свернуть:**
-
-```
-ssh ha 'sudo docker rm -f ttv-wedge-stand'
-ssh ha 'sudo docker exec hassio_cli ha apps start b34a1737_torrent_tv_proxy'
-```
-
-**Почему свой контейнер, а не правка живого.** Пробовал патчить контейнер
-дополнения — не выживает: `ha apps restart` пересоздаёт его из образа, а
-убийство процесса внутри поднимает watchdog, который тоже пересоздаёт. Дважды
-проверено по дате создания контейнера. Свой контейнер watchdog не трогает.
-
-**Что построено в продукте** (в npm НЕ опубликовано, в git НЕ закоммичено):
-`--send-chunk-bytes <N>` — размер одного сообщения канала данных;
-`bodySender` — чистая функция нарезки и склейки, восемь проверок
-(`test/send-chunk-bytes.test.js`), одна проверена на красноту поломкой склейки
-через границу чтения; `msgBytes=` в строке `[net-debug]`; `chunks=` теперь
-считает сообщения, а не чтения тела. Запись в CHANGELOG на 2.83.7.
-
-**Как сменить размер** (стенд перезапускается изнутри своего контейнера):
-
-```
-ssh ha 'sudo docker exec ttv-wedge-stand pkill -f cli.js'
-ssh ha 'sudo docker exec -d ttv-wedge-stand sh -c "node /usr/local/lib/node_modules/@torrent-tv/proxy/bin/cli.js --server-url https://webauth.courses --host 0.0.0.0 --port 9090 --ffmpeg-bin /usr/bin/ffmpeg --state-dir /standdata --delivery-sink --send-chunk-bytes 16384 --name wedge-stand > /standdata/stand.log 2>&1"'
-```
-
-**Нагрузка** ставится одним вызовом `evaluate_script` в открытой на
-`webauth.courses` вкладке Chrome (9222, chrome-devtools MCP): цикл поднимает
-СВОЁ соединение `new WebRtcProxy(id)` — рабочее соединение страницы не
-трогается, — тянет `GET /api/delivery-sink?bytes=4194304` подряд и пишет отчёты
-через `POST /api/client-logs`, то есть по HTTP, мимо заклинивающего канала.
-Состояние лежит в `window.__WEDGE_STAND__`, остановка — `.stopped = true`.
-
-**Читать результат:**
-
-```
-ssh do 'docker logs --tail 400 infra-server-1' | grep wedge-stand
-ssh ha 'sudo docker exec ttv-wedge-stand grep msgBytes /standdata/stand.log | tail -5'
-```
-
-**Ловушка, стоившая одного прогона:** локальный стенд на машине разработчика
-назывался тем же именем `wedge-stand`, и цикл подключился к нему вместо ХА.
-Целиться по id, не по имени. Локальный остановлен.
-
-**Опорный прогон запущен 2026-09-12 23:36 UTC** на `f312d1e6`, размер `asread`
-(65 382 байта), 4 МБ на запрос, 190-325 Мбит/с. Результата на момент записи нет.
+# Передача: клин доставки, стенд и werift — 2026-09-13
+
+Написано для того, кто продолжит. Всё, что ниже, либо прочитано из журналов и
+кода, либо помечено как непроверенное.
+
+## 1. Что установила сессия 2026-09-12 (прокси 2.83.5)
+
+Показ встал на **521,2 с фильма** и не возобновился. Причина — клин доставки,
+и он снят на проводе с обеих сторон. Разбор:
+`research/delivery-wedge-on-the-wire-2026-09-12.md`.
+
+Цепочка, каждое звено с числом из журнала:
+
+1. 21:50:39.658 — последнее, что браузер получил. Его счётчик канала
+   `proxy=12112msg/479898176B` не сдвинулся больше ни разу;
+2. прокси продолжал отдавать: `sent=485243979 → 485263428`, очереди
+   `queued[proxy:0B proxy-control:0B proxy-fast:0B]`, `rtt=24ms`,
+   `pc=connected ice=completed`. Обратное направление работало весь клин;
+3. через ассоциацию прошло **485 МБ**. Прежние эпизоды: 783, 813, 825, 2294 МБ.
+   Порога по объёму нет;
+4. обрыв пойман посреди отдачи одного куска: `bytes=10657210 sendMs=360
+   bufferedAtEnd=0` — usrsctp принял всё, очередь пуста; на проводе за
+   следующие три секунды ушло 6 727 961 байт (≈63 %), и в середине четвёртой —
+   ноль, без ретрансмиссий и без утоньшения подтверждений.
+
+**Лечение было измерено и выброшено.** Браузер поднял вторую ассоциацию к тому
+же пиру, прокачал `GET /api/delivery-sink?bytes=4194304` за 140 мс, записал
+`the fault is held in the wedged association` — и **закрыл её через 0,45 с**.
+Показ остался на мёртвой.
+
+**Почему зритель сидит навсегда, а не минуту:** лестница пересоединения не
+запускается. В клиентском журнале нет ни `transport lost`, ни `reconnect
+attempt`, потому что заклинивший канал остаётся `state=connected
+ice=connected`, и объявлять его потерянным нечему. В тот же вечер в 20:03 на
+ЗАКРЫТОМ канале та же лестница отработала штатно.
+
+## 2. Две поправки к роадмапу, сделанные чтением кода
+
+1. **`waitForBufferDrain` УЖЕ починен** (`services/data-channel-handler.js:1199`,
+   выпущено в 2.80.6): он ждёт нижней отметки с опросом каждые 50 мс,
+   постоянная `DC_BUFFER_DRAIN_TIMEOUT_MS` удалена. Запись в роадмапе
+   («fails open», 2026-09-06) устарела.
+2. **И он всё равно не защищает.** В поле 2026-09-12 `bufferedAtEnd=0` и
+   `drainMs=0` на каждой строке: наша очередь пуста, потому что libdatachannel
+   отдал байты в usrsctp, а держит их usrsctp. `bufferedAmount()` слеп к этому
+   по построению — прокси отдал 10,6 МБ в тишину и не узнал.
+
+**Что на месте этого предложено и НЕ построено:** backpressure по тому, что
+зритель ПОДТВЕРДИЛ. Браузер уже сообщает счётчики каждого канала
+(`proxy=12112msg/479898176B` в строке `[dc-far]`, раз в 500 мс). Отправка
+сверяется с ними, а не только с `bufferedAmount()`. Порог не выбирать — вывести
+из того, сколько байт эта связь держит в полёте при здоровой работе.
+
+## 3. Обновление зависимости — проверено, не лечит
+
+Пин `^0.32.0`, в npm **0.33.4**. Внутри libdatachannel 0.24.2 → 0.24.5.
+Подмодуль usrsctp сверен по четырём тегам (v0.24.2, .3, .4, .5):
+`fec583d54493f879d2ae44a743423bf8a04371ab` во всех. **От клина не лечит.**
+Запись роадмапа «upstream fix waiting нет» была верна на 26.08; теперь
+перепроверена и по-прежнему верна по существу, но libdatachannel ушёл вперёд
+на три версии (там исправление прерывистых отказов DTLS-рукопожатия).
+
+## 4. werift — исследовано, читая сам пакет
+
+werift 0.24.4, MIT, обновлён 2026-08-10, один автор. 4,2 МБ, 9 зависимостей.
+`ice/`, `dtls/`, `sctp/`, `rtp/`, `webrtc/` — полная реализация на TypeScript.
+
+**За:**
+1. usrsctp исчезает целиком, а с ним и подозреваемый;
+2. ни одной нативной зависимости (`@noble/curves`, `tweetnacl`,
+   `@peculiar/x509` — чистый JS). Ни prebuilt, ни musl/aarch64, ни сборки в
+   дополнении. Для проекта с одним форком нативного модуля и девятью смертями
+   процесса это существенно;
+3. `bufferedAmount`, `bufferedAmountLow`, `bufferedAmountLowThreshold` есть —
+   наш backpressure переносится.
+
+**Против:**
+1. **Мультиплексирования одного UDP-порта нет.** `lib/common/src/transport.js:130`
+   создаёт `dgram.createSocket` на соединение; `icePortRange` — диапазон, а не
+   общий сокет. У нас `IceUdpMuxListener` держит один порт 9090 на все сессии,
+   и ровно он замаплен UPnP — шаг 3 удалённого доступа (2.9.18). На werift
+   каждая сессия берёт свой порт, которого в маппинге нет;
+2. **Цена в процессоре не измерена и может быть запретительной.**
+   `lib/sctp/src/sctp.js:16` — `USERDATA_MAX_LENGTH = 1200`. Сообщение в 65 КБ
+   режется на 55 SCTP-кусков, каждый собирается в JS, CRC32c через
+   `Buffer.concat` на пакет (`chunk.js:763`), поверх — DTLS-шифрование на JS.
+   При 8 Мбит/с ≈830 пакетов/с; на измеренных 24.08 пиках 150-330 Мбит/с —
+   за 30 000/с. На CM4, который кодирует 1080p на 1,96x.
+
+**Вывод:** werift снимает подозреваемого и платит сломанным единым портом и
+неизвестной производительностью. Назвать его решением до замера нельзя.
+Замер дешёвый: поднять werift-приёмник, прокачать гигабайт, сравнить загрузку
+процессора с сегодняшней.
+
+## 5. Стенд — построен наполовину, упёрся в выбор прокси
+
+Цель: измерить, ЗАВИСИТ ЛИ КЛИН ОТ РАЗМЕРА ПОРЦИИ. Это гейт на всё остальное,
+и он не снят ни разу — стенд 26.08 прокачал 1,0 ГБ без отказов, но его
+приёмник был libdatachannel, а нужен dcSCTP браузера.
+
+**Что работает:** `chrome-devtools` MCP подключён к Chrome 155 на 9222
+(`list_pages` отвечает). Локальный прокси поднимается и регистрируется:
+
+```
+node bin/cli.js --server-url https://webauth.courses --port 9091 \
+  --delivery-sink --name wedge-stand --log-file <path>
+```
+
+**Что мешает:** браузер его не выбирает. Дважды подряд, включая после
+перезагрузки страницы:
+
+```
+selectedId: f3013ad3 (полевой, хост дополнения)
+candidates: wedge-stand score=0.6075, proxy-f3013ad3 score=0.4466
+```
+
+Стенд имеет ЛУЧШИЙ счёт и не выбран. Отличие одно: `reachable: false` —
+сервер дозванивается снаружи и до машины разработчика не достаёт. Значит
+нагрузка пошла бы на рабочий узел, чего делать нельзя.
+
+**Два выхода, решение за пользователем:** сделать стенд достижимым (проброс
+порта) или добавить способ назначить прокси явно (правка продукта ради
+стенда).
+
+**Оговорка, которую надо держать при любом прогоне:** клин наступал при 485,
+783, 813, 825 и 2294 МБ — разброс впятеро. Одна прогонка на значение не
+докажет ничего; нужно по нескольку, и это часы прокачки. Если разброс внутри
+одного размера порции останется таким же, честный ответ — «не установлено», а
+не число.
+
+**Механика автономного прогона, продуманная и не построенная:** фоновый
+процесс через `run_in_background`; цикл в странице ставится ОДНИМ вызовом
+`evaluate_script` и дальше живёт сам; результат выходит через `client-logger`
+на сервер, а не через канал данных, — этот путь HTTP и переживает клин, чего
+сегодня не хватило (пункт 85: браузер замолчал ровно на клине).
+
+## 6. Что делать дальше, по порядку
+
+1. снять препятствие со стендом и взять замер размера порции — это гейт;
+2. backpressure по подтверждённому зрителем (§2), целиком наш код;
+3. замер werift на процессоре, если §1 не даст ответа;
+4. сообщить наверх: у нас есть то, чего нет ни у кого — два захвата с обеих
+   сторон и доказательство, что вторая ассоциация к тому же пиру работает в ту
+   же секунду. Ни в libdatachannel, ни в usrsctp вопрос не открыт.
+
+**Чего делать НЕ надо:** прямой HTTPS (шаги 6-7) как ответ на этот клин.
+Сказано пользователем 2026-09-12: это не решение проблемы.
+
+## 7. Что осталось незакрытым от прошлых сессий и всплыло сегодня
+
+1. ложное срабатывание 21:13:34 при 76 МБ прокачанных — 180 с захвата и файлы
+   кольца на показ, который шёл дальше ещё 37 минут;
+2. `--delivery-sink` включён на полевом прокси. Он отдаёт ответ любого размера
+   и существует только для стенда.
+
+## 8. СОСТОЯНИЕ НА КОНЕЦ 2026-09-12: дополнение ОСТАНОВЛЕНО, на его месте стенд
+
+**Смотреть нельзя, пока это не свёрнуто.** Дополнение остановлено намеренно
+(`ha apps stop b34a1737_torrent_tv_proxy`), и его место на порту 9090 занял
+контейнер `ttv-wedge-stand`, запущенный из того же образа
+(`b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`) с пропатченными
+`services/data-channel-handler.js` и `bin/cli.js`.
+
+**Свернуть:**
+
+```
+ssh ha 'sudo docker rm -f ttv-wedge-stand'
+ssh ha 'sudo docker exec hassio_cli ha apps start b34a1737_torrent_tv_proxy'
+```
+
+**Почему свой контейнер, а не правка живого.** Пробовал патчить контейнер
+дополнения — не выживает: `ha apps restart` пересоздаёт его из образа, а
+убийство процесса внутри поднимает watchdog, который тоже пересоздаёт. Дважды
+проверено по дате создания контейнера. Свой контейнер watchdog не трогает.
+
+**Что построено в продукте** (в npm НЕ опубликовано, в git НЕ закоммичено):
+`--send-chunk-bytes <N>` — размер одного сообщения канала данных;
+`bodySender` — чистая функция нарезки и склейки, восемь проверок
+(`test/send-chunk-bytes.test.js`), одна проверена на красноту поломкой склейки
+через границу чтения; `msgBytes=` в строке `[net-debug]`; `chunks=` теперь
+считает сообщения, а не чтения тела. Запись в CHANGELOG на 2.83.7.
+
+**Как сменить размер** (стенд перезапускается изнутри своего контейнера):
+
+```
+ssh ha 'sudo docker exec ttv-wedge-stand pkill -f cli.js'
+ssh ha 'sudo docker exec -d ttv-wedge-stand sh -c "node /usr/local/lib/node_modules/@torrent-tv/proxy/bin/cli.js --server-url https://webauth.courses --host 0.0.0.0 --port 9090 --ffmpeg-bin /usr/bin/ffmpeg --state-dir /standdata --delivery-sink --send-chunk-bytes 16384 --name wedge-stand > /standdata/stand.log 2>&1"'
+```
+
+**Нагрузка** ставится одним вызовом `evaluate_script` в открытой на
+`webauth.courses` вкладке Chrome (9222, chrome-devtools MCP): цикл поднимает
+СВОЁ соединение `new WebRtcProxy(id)` — рабочее соединение страницы не
+трогается, — тянет `GET /api/delivery-sink?bytes=4194304` подряд и пишет отчёты
+через `POST /api/client-logs`, то есть по HTTP, мимо заклинивающего канала.
+Состояние лежит в `window.__WEDGE_STAND__`, остановка — `.stopped = true`.
+
+**Читать результат:**
+
+```
+ssh do 'docker logs --tail 400 infra-server-1' | grep wedge-stand
+ssh ha 'sudo docker exec ttv-wedge-stand grep msgBytes /standdata/stand.log | tail -5'
+```
+
+**Ловушка, стоившая одного прогона:** локальный стенд на машине разработчика
+назывался тем же именем `wedge-stand`, и цикл подключился к нему вместо ХА.
+Целиться по id, не по имени. Локальный остановлен.
+
+**Опорный прогон запущен 2026-09-12 23:36 UTC** на `f312d1e6`, размер `asread`
+(65 382 байта), 4 МБ на запрос, 190-325 Мбит/с. Результата на момент записи нет.