docs: describe call audio startup and loss tone gating

doc/chat_call_arch.md

@@ -115,6 +115,13 @@ CM handle инициирует оптимальное подключение и
 GUI запускает аудиоустройство по CALL_ACCEPTED. При CALL_ENDED начинается финальный тон;
 устройство останавливается перед `call_audio_release`. Явное завершение звонка прекращает
 воспроизведение накопленной речи и включает тон завершения — на обеих платформах.
+Android останавливает гудки до настройки звонкового аудиотракта. После выбора маршрута
+и создания AudioRecord поток захвата начинает отправку, затем создаётся и запускается AudioTrack.
+Ошибка подготовки playback останавливает и дожидается уже запущенного захвата через общий `stop()`.
+Маршрутизатор использует один снимок входных/выходных устройств; обновляет его при старте,
+событиях устройств/BT-профиля и явной переоценке. По завершении снимок освобождается.
+INFO-логи Android показывают длительности настройки режима, маршрута, создания/старта устройств
+и время первого кадра захвата. Общий `call_audio` логирует время ожидания первого PCM.
 
 ## 7. Буфер звонка и восстановление
 
@@ -146,13 +153,15 @@ SoundTouch: `USE_QUICKSEEK=1, SEQUENCE_MS=20, SEEKWINDOW_MS=10, OVERLAP_MS=4`.
     устанавливается) — гудок «соединение» (короткие бипы);
   - фаза 2 «звоним» (`RINGING`: получен RINGING, у пира идёт вызов) — длинные гудки (ringback).
   Гудки генерируются платформенно-нативно: desktop — цикличные MP3 через `SoundManager`
-  (`call_connecting`/`call_ringing`), Android — `ToneGenerator`
-  (`TONE_SUP_DIAL`/`TONE_SUP_RINGTONE`). Переключение — по `CHAT_EVT_CALL_RINGING`,
+  (`call_connecting`/`call_ringing`), Android — цикличные MP3 через `CallRingback`/`MediaPlayer`.
+  Переключение — по `CHAT_EVT_CALL_RINGING`,
   остановка — по `CALL_ACCEPTED`/`CALL_ENDED`/`CALL_ERROR`/hangup.
-- **Отсутствие медиа ≥500мс при недоборе PCM** (нет входящих медиа) → в `call_audio_pull_pcm` воспроизводится
+- **Начальное ожидание первого PCM** → тишина без сигнала потери звука. Подготовка удалённого микрофона
+  и начальное накопление jitter не считаются перебоем. Существующий таймаут 20с без медиа действует с ACTIVE.
+- **Недобор PCM ≥500мс после начала воспроизведения** → в `call_audio_pull_pcm` воспроизводится
   `CALL_TONE_GLITCH`: `пи-пи (2×150мс, gap 100мс) … тишина до 1.0с … пи(200мс)
   пауза(200мс) пи(200мс)`, 1000 Гц, цикл пока длится сталл. До порога — тишина при нехватке PCM.
-  При восстановлении медиа или полном запросе PCM сигнал останавливается.
+  При возобновлении PCM сигнал останавливается; одного входящего пакета без достаточного запаса недостаточно.
 - **Завершение звонка → всегда** `CALL_TONE_ENDED`: 3 нисходящих 700/500/400 Гц по 150 мс.
 - Счётчики: tx/rx кадры, `c_tx_dropped`/`c_rx_dropped`, дропы буфера, сталлы,
   tempo-события, причины завершения. Логи `DEBUG_CATEGORY_CALL` (+стата раз в 1с).

doc/tasks.md

@@ -53,21 +53,22 @@
     capture/playback, фактической частоты callback и PCM кадров за интервал.
     Счётчики сбрасываются до старта устройства; нужна повторная запись с новой сборкой.
 
-[ ] **Ложный сигнал потери звука при запуске звонка** — 01.10.2026, звонок
-    `bc3efadcac629947`: Qt начинает PCM в 01:54:56.933, включает gap tone в
+[+] **Ложный сигнал потери звука при запуске звонка** — 01.10.2026, звонок
+    `bc3efadcac629947`: Qt запускает аудиоколлбэки в 01:54:56.933, включает gap tone в
     01:54:57.415 и выключает в 01:54:58.072 при первом воспроизведении PCM.
     На SM между ACCEPT и первым захваченным кадром проходит около 1.15с;
     часы SM отстают примерно на 1.23с. Qt стабильно обслуживает 100 callback/с,
-    RTT около 1мс. `call_audio_pull_pcm()` считает начальное ожидание первого PCM
-    таким же перебоем, как потерю уже работавшего звука, и включает тон через 500мс.
-    Разделить ожидание первого воспроизведения и последующий перебой;
-    стартовый сбой по-прежнему ограничен существующим watchdog отсутствия медиа.
+    RTT около 1мс. Исправлено: до первого PCM начальное ожидание проходит в тишине,
+    последующий перебой включает тон через 500мс. Стартовый сбой по-прежнему
+    ограничен существующим watchdog отсутствия медиа. Регрессия проверяет ожидание
+    1.5с, начальное накопление, настоящий перебой, неполный блок, новый звонок и завершение.
     Ускорение запуска Android: router.start занимает около 775мс; система сообщает
     длительное удержание AudioManager.updateAudioPortCache. Ещё около 370мс проходит
-    до запуска capture worker. CallController останавливает гудки только после
-    startAudio; перенести остановку перед ним, сократить повторное перечисление
-    устройств в router и запускать capture до подготовки/старта playback.
-    Добавить длительности отдельных стадий; выигрыш перестановок пока не измерен.
+    до запуска capture worker. Гудки теперь останавливаются до startAudio;
+    router использует снимок устройств с обновлением по событиям и явной переоценке,
+    capture запускается до подготовки/старта playback. Ошибка playback останавливает capture.
+    Добавлены длительности отдельных стадий, первого capture и PCM. Ядро, Qt и APK
+    собраны после clean; три аудиотеста прошли. Выигрыш на SM требует замера в новом звонке.
 
 [ ] **Гонка invite-файла в test_chat_join_e2e** — `wait_file()` проверяет только
     существование файла, а `wf()` создаёт его до записи. Читатель иногда получает