Clarify audio diagnostic timing and reporter lifetime

doc/chat_call_arch.md

@@ -138,7 +138,7 @@ INFO-логи Android показывают длительности настро
 на API 26–30 запрашивается такой эффективный размер буфера, с учётом ограничений устройства.
 Прежнее заполнение всей ёмкости на Samsung оставляло около 140мс между written и played
 (на desktop 60–80мс). Лог `playback buffering` показывает принятый порог и ёмкость;
-ежесекундный `clock` — queuedUs, текущий порог и underruns, прирост underruns имеет уровень WARN.
+ежесекундный `audio summary` — queueUs, текущий порог и underruns; новый episode underrun имеет уровень WARN.
 Это очередь AudioTrack, а не полная сквозная задержка и не сетевой jitter reserve.
 Повторный замер: startFrames=1920 принят, но written-played остался 140мс; одного стартового порога недостаточно.
 
@@ -148,9 +148,19 @@ INFO-логи Android показывают длительности настро
 целевым запасом/разбросом доставки JB, темпом, недостающим PCM и отдельными счётчиками JB/AudioTrack.
 Снимок JB не сбрасывает события для CALL_STATS. encodedMs — очередь Opus после pull,
 processingMs — оставшийся PCM SoundTouch в длительности исходной речи; reserveMs зависит только от доставки.
-AudioTimestamp опрашивается раз в 200мс, его frame/time и время опроса печатаются отдельно;
+Reporter опрашивает AudioTimestamp, routedDevice, underrunCount и размеры буфера не чаще раза в 200мс.
+Playback читает только опубликованный неизменяемый снимок. Его begin/end и возраст deviceAgeUs
+отличают задержку опроса от задержки аудио; stampQueryUs/routeQueryUs/propertiesQueryUs показывают стоимость запросов.
+Android API может удерживать общие внутренние locks даже при вызове из reporter: перенос убирает
+прямое ожидание диагностического запроса в playback, но сам по себе не доказывает отсутствие влияния на write/head.
+frame/time аппаратного timestamp и время начала опроса печатаются отдельно;
 при недоступности стоит stampOk=0. Времена trace — MONOTONIC; очередь устройства — written-played.
 Эти показатели нельзя складывать с возрастом AudioTimestamp как независимые задержки.
+В playback отдельно измеряются writeCallUs (только вызовы write), headCallUs (чтение позиции),
+progressCallUs (публикация позиции ядру), jbSnapshotUs (нативный снимок), writeSpanUs (весь цикл записи)
+и blockUs (pull до формирования строки). При частичных записях длительности вызовов суммируются за блок.
+Старое поле writeUs включало чтение позиции и прогресс: его нельзя трактовать как длительность одного AudioTrack.write.
+Stop дожидается reporter, включая непрерываемый Android-запрос, до освобождения AudioTrack.
 
 `audio detail` сохраняет 2с до и 3с после старта, фактической смены routedDevice или новой аномалии:
 очередь устройства >100мс в течение секунды, отсутствие продвижения head 100мс при наличии данных,