- Исправлена задержка доставки MUC с растущим архивом: после каждого

сообщения
  больше не выполняется полный scan/rewrite архива для expiry. Очистка
  остаётся
  в maintenance и перед MAM-запросами; append и crash checkpoint до
  fanout сохранены.
- Неизменённые native config/persistent index не перезаписываются при
  каждом
  сообщении. Удалённые файлы восстанавливаются, ошибки экспорта
  повторяются.
- CSI больше не сохраняет SM snapshot при отсутствии изменения durable
  очереди.
  Изменённая очередь сохраняется до отправки; при ошибке записи очередь
  откатывается.
- Личные сообщения, IQ и входящая федерация к аккаунтам больше не
  захватывают
  общий MUC mutex, ожидая несвязанную работу с комнатными архивами.
- Добавлены регрессии native exports/archive scanning/CSI rollback и
  реальный
  TLS latency check в verify-local.sh, автоматически включённый и в CI.

Измерения и границы подтверждения:
[docs/MESSAGE-LATENCY.md](docs/MESSAGE-LATENCY.md).
Результаты итогового прогона:
[docs/VALIDATION-0.8.1.md](docs/VALIDATION-0.8.1.md).

- Личные сообщения и SM ACK больше не ждут сетевую отправку push.
  Уведомления
  отправляются через очередь1024 с максимум8параллельных маршрутов;
  worker
  и его задачи отменяются при завершении serve. Ошибки очереди/маршрута
  логируются.
- Offline сообщение сохраняется до публикации push, чтобы проснувшийся
  клиент
  мог сразу получить его. Подтверждена очередь при первом TLS stream
  push gateway.
- По умолчанию CSI считает важными bodyless OMEMO legacy/2, delivery
  receipts
  и chat markers. Явный список `csi_important_payloads` заменяет
  расширенные defaults.
  Низкоприоритетный headline по-прежнему буферизуется. Policy
  обновляется и при SM resume.
- Выбор адресатов и carbons фильтрует владельцев до захвата session
  mutex;
  зависшая сессия чужого аккаунта не задерживает этот путь. Duplicate SM
  ACK
  без изменения durable counters/queue не переписывает snapshot.
- Bind2 и MAM metadata IQ читают только первый/последний native record
  вместо
  сканирования всей истории. Индекс не требуется; recovery/лимиты записи
  сохранены.
- Добавлен `message-processing-slow`: обработка message дольше250мс,
  поля
  duration_ms/route, без payload/токенов. Это время обработки сервером,
  не peer receipt.
- Новые сетевые регрессии включены в verify-local.sh/GitHub CI.

Причины, изменение CSI policy, измерения и ограничения:
[docs/PERSONAL-MESSAGE-LATENCY.md](docs/PERSONAL-MESSAGE-LATENCY.md).

docs/MESSAGE-LATENCY.md

@@ -0,0 +1,63 @@
+# Задержка доставки: исправление 0.8.1
+
+В0.8.0 MUC после каждого groupchat append запускал expire_before. Эта операция
+под общим mutex компонента проходила по всему архиву и записывала сохранённые
+записи во временный файл даже при отсутствии истёкших записей. Задержка каждого
+сообщения росла с размером истории. Дополнительно переписывались неизменённые
+native room config/persistent index, а CSI сохранял полную durable SM-сессию
+даже при пустой/неизменённой очереди.
+
+В0.8.1 эти лишние операции исключены из обычного пути доставки. Очистка архива
+остаётся в периодическом maintenance (интервал сервера300с) и перед MAM-запросами.
+Неизменённые native-файлы не переписываются; недостающие/изменённые экспорты и
+повтор после ошибки сохранены. Авторитетный MUC checkpoint и SM state по-прежнему
+записываются до подтверждения соответствующих изменений. CSI откатывает изменение
+очереди при ошибке checkpoint. Ненаправленный в MUC account traffic обходит mutex
+компонента и не ждёт его обслуживания архивов.
+
+## Измерение
+
+Настоящий STARTTLS, два клиента, durable SM, MUC MAM с finite retention,
+active/inactive CSI. Изолированный loopback; архив native `.list` заполнен до
+запуска сервера. Проверяются доставка sender echo/peer, counters, durable CSI
+buffer/flush и точное число записей архива. Порог задержки в миллисекундах не
+используется как flaky assertion; структурные регрессии запрещают полный scan
+архива при append и запись неизменённых native-файлов.
+
+Active CSI, MUC peer, мс:
+
+| Записей истории | 0.8.0 median / p95 | 0.8.1 median / p95 |
+|---:|---:|---:|
+|0|9.425 / 11.221|5.054 / 7.643|
+|1000|32.718 / 36.995|4.280 / 6.605|
+|10000|259.472 / 269.067|4.895 / 6.307|
+|100000|2517.940 / 2520.941|4.680 / 14.532|
+
+Inactive CSI,100000 записей: median3866.027→4.285мс,
+p95 4150.867→5.072мс. Первые три строки —5samples/state, последняя —3.
+Это ограниченное сравнение на одном loopback host, а не production SLA и не
+доказательство всех возможных причин задержки у реальных клиентов.
+Полные сырые samples и SHA-256 обеих сборок — validation-logs-0.8.1/latency-*.json.
+
+Команды:
+
+```bash
+python3 tests/message_latency_network.py --binary target/release/rust-xmpp \
+  --rounds 5 --history-records 0 1000 10000 --output /tmp/message-latency.json
+python3 tests/message_latency_network.py --binary target/release/rust-xmpp \
+  --rounds 3 --history-records 100000 --output /tmp/message-latency-100k.json
+```
+
+Быстрая проверка0/10000 records уже включена в verify-local.sh и GitHub Actions.
+Для повторной медленной проверки используйте сохранённую0.8.0 release-сборку;
+не приписывайте исходному бинарнику результаты пересобранной новой версии.
+
+## Если задержка остаётся в целевой установке
+
+Сопоставьте время отправки, получения и отображения delivery/read receipt,
+тип чата, transport, состояние CSI и наличие федерации. Доставка сообщения и
+receipt — разные события. Native CSI policy для низкоприоритетных payload не
+менялась. Длительный MAM query, периодическая очистка большого архива, медленный
+диск или внешний XMPP-домен могут иметь отдельную задержку. Текущие изменения
+не отключают fsync, не обещают exactly-once и не подменяют проверку реальных
+Conversations/Monal/Gajim либо deployment.