feat(tx): тихий детектор голодания очереди TX

Всплеск, рождённый нашим трактом, невозможен без одного события: очередь DUC
простаивает дольше подушки отправителя (DUC_FIFO_THROTTLE = 2000 отсчётов при
192 кГц = 10.42 мс). Съём 2026-08-21 это показал прямо: шесть всплесков — шесть
простоев 10.3-23.5 мс, а паузы 8 мс и короче не дали ни одного. Значит счётчик
таких простоев — полный детектор «наш/не наш», и оператору больше не нужно
называть интервал на глаз.

Новый юнит TxHealth.pas. Включён всегда: переменной окружения нет намеренно —
прибор, который надо не забыть включить, к моменту дефекта выключен.

* поток отправителя DUC мерит каждый простой очереди на передаче — одно чтение
  монотонных часов на ПЕРЕХОД, ни файлов, ни локов (обе ветки, win и unix);
* планировщик TCI публикует рядом состояние пейсинга (аванс, долг, в полёте,
  квант, шаг, период пачек клиента) — простыми записями, без лока: числа
  диагностические, а лок в потоке отправителя DUC недопустим для тайминга;
* сетевой поток считает бит HPS_FIFO_EMPTY из HP-статуса радио — поле ГЛУБИНЫ
  FIFO на этой прошивке статично (256) и веры ему нет, а бит мы не читали вовсе;
* ★журнал пишет ТОЛЬКО потребитель — таймер UI (100 мс) и цикл демона через
  TxHealthService. В тракте передачи диска нет по построению.

Последнее — правило, оплаченное регрессом: прошлый прибор (TxTrace) сбрасывал
дамп синхронно в хвосте SetMOX, и эти десятки миллисекунд закрывали гонку в
пейсинге TCI (лечение — fa38fa7). Инструмент чинил дефект собой.

Журнал ~/.config/ewsdr/txhealth.log, строка на передачу: «чисто» либо «ОПАСНО
(первое на N мс)» плюс подробности с контекстом пейсинга. В статусной строке
UI — «·сухо N» за сеанс, чтобы не помнить, какая посылка была плохой.

Стенд: секция G в test/tci (порог подушки, сводка, момент от фронта PTT,
контекст рядом с событием, молчание вне передачи) — 276/276. Диск стенд не
трогает намеренно: берёт сводки через TxHealthTake/TxHealthDetail, мимо
TxHealthService, иначе писал бы в настоящий журнал пользователя.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bkwwyj7xVRrqnSVEseTRfV

test/hpsdr/README.md

@@ -105,6 +105,55 @@ TX голодала, в эфире дыры. Тут же диапазон глу
 * `capture.sh` — кольцевой съём tcpdump + лог потерь ядра.
 * `pcap_tx_scan.py` — разбор pcap, чистый Python без зависимостей (~40 МБ/с).
 
+## Тихий детектор голодания очереди TX (включён всегда)
+
+Всплеск, рождённый НАШИМ трактом, невозможен без одного события: очередь DUC
+простаивает дольше подушки отправителя (`DUC_FIFO_THROTTLE` = 2000 отсчётов при
+192 кГц = **10.42 мс**). Это доказано съёмом 2026-08-21: шесть всплесков — шесть
+простоев 10.3–23.5 мс, паузы 8 мс и короче не дали ни одного. Поэтому счётчик
+таких простоев — **полный** детектор, и он теперь живёт в самой программе
+(`TxHealth.pas`), без переменных окружения: прибор, который надо не забыть
+включить, к моменту дефекта выключен.
+
+Что делает:
+
+* поток отправителя DUC мерит каждый простой очереди на передаче — одно чтение
+  монотонных часов на переход, ни файлов, ни локов;
+* планировщик TCI публикует рядом состояние пейсинга (аванс, долг, в полёте,
+  квант, шаг, период пачек клиента) — простыми записями;
+* сетевой поток считает биты «DUC FIFO пуст» из HP-статуса радио (поле ГЛУБИНЫ
+  на этой прошивке статично и веры ему нет, а бит раньше не читался вовсе);
+* журнал пишет **потребитель** — таймер UI (100 мс) или цикл демона, никогда не
+  тракт передачи.
+
+★Последнее — правило, оплаченное регрессом: прошлый прибор (`TxTrace`) сбрасывал
+дамп синхронно в хвосте `SetMOX`, и эти десятки миллисекунд закрывали гонку в
+пейсинге TCI. С зондами всплесков не было, без них они возвращались —
+инструмент чинил дефект собой (лечение: коммит `fa38fa7`).
+
+Журнал: `~/.config/ewsdr/txhealth.log`, по строке на передачу.
+
+```
+2026-08-24 19:08:03  ОПАСНО (первое на 100 мс)  передача 12.4 с, источник TCI: осушений 17, опасных 1, самое длинное 18.0 мс, FIFO-EMPTY 0
+    опасный #1: на 100 мс от PTT, 18.0 мс, очередь 0, аванс 3584, долг 2200, в полёте 1024, квант 512, шаг 5333 мкс, пачка клиента 44.1 мс
+```
+
+Как читать:
+
+* **`чисто`** — за эту передачу очередь ни разу не пересыхала дольше подушки.
+  Значит увиденный всплеск родился НЕ в нашем тракте: смотреть приёмный тракт
+  (дыра в DDC — на экране есть, в эфире нет), PA, реле, спуры.
+* **`ОПАСНО`** — простой был, и подробная строка называет виновника по контексту:
+  пачка клиента длиннее аванса (`пачка клиента` > `аванс`/48 мс) — зернистость
+  MSHV; `долг` у потолка при малом `в полёте` — планировщик не успевает;
+  `шаг` заметно больше половины кванта — проспал поток планировщика.
+* Строка статуса в UI показывает `·сухо N` — сколько опасных простоев набралось
+  за сеанс, чтобы не приходилось помнить, какая посылка была плохой.
+
+Правило разбора то же, что и с pcap: **дальше сопоставлять**. Детектор говорит
+«очередь сохла в такой-то момент», `pcap_tx_scan.py` по тому же куску времени
+скажет, ушёл ли всплеск в эфир или это артефакт приёма.
+
 ## Приборы внутри процесса: кольцевая трассировка TX-тракта
 
 ★**Сняты из кода 2026-08-24** — пейсинг TX проверен на железе, всплесков нет, и