doc: durability SendMessageBatch + billing (предусмотрен, выключен)

doc/thinking/vm-public-entrypoint-2026-10-10.md

@@ -155,3 +155,21 @@ curl -sS https://sqs.sinefo.ru/health
 **Почему пока два листенера в одном процессе, а не два процесса:** состояние (очереди/тенанты) —
 in-memory; два процесса разъедутся (админка создаст тенанта в своей памяти — data-plane его не увидит).
 Полноценный процесс-split — после Шага 3 (Redis как источник истины).
+
+## 11. Надёжность записи (durability) и billing (2026-10-10)
+
+### 11.1. Синхронная запись критичных операций
+- `SendMessage` — sync (`SaveMessageSync`, фикс P1.1) ✅
+- `DeleteMessage` / `DeleteMessageBatch` — sync (`DeleteMessagePersist`/`DeleteMessagesPersist`) ✅
+- **`SendMessageBatch` — ИСПРАВЛЕНО (коммит `3559414`):** было `SaveMessages` (async) → стало
+  `SaveMessagesSync` (ответ 200 только после записи всех сообщений; при ошибке — откат append).
+  Заодно: не персистим дубли (раньше в Redis попадали дубликаты, которых нет в очереди).
+- Проверено: batch из 2 сообщений в пустую очередь **пережил рестарт** сервиса.
+- Остаётся async: `SaveQueue` (метаданные очереди: FIFO-состояние, duplicates) и метаданные
+  в Create/Delete/SetAttributes/Purge/Tags — потеря возможна только в узком окне при крахе;
+  сами сообщения защищены.
+
+### 11.2. Billing — предусмотрен, но НЕ включён
+- Модуль есть (`app/billing`, PG-воркер + буфер), включается через `BILLING_PG_HOST` (сейчас не задан).
+- Решение: **оставить выключенным**; включать, когда появятся реальные клиенты/тарификация.
+- Учёт операций уже рассчитан под биллинг — при включении заработает без изменений ядра.