отработаны находки ревью кода

Триаж свёл 62 сырые находки девяти проходов к 33 причинам: 3 блокера,
4 «сейчас», 2 развилки. Все закрыты регрессионными тестами.

- схема точки сна определяется по самой точке, а не по индексу в исходном
  массиве: одна пропущенная точка меняла эпизод и сводку местами
- доставка сворачивается одной транзакцией: частичное состояние было
  недетерминированным (восемь прогонов — семь состояний)
- граница размера на распакованном теле: 400 КиБ gzip разворачивались в
  400 МиБ мимо max_body_mb
- столкновение — расхождение канонических форм, а не байтов; WARN с
  координатами объекта; payload без HTML-экранирования
- выравнивание по местной метке: получасовые зоны уводили часовую выгрузку
  в minute
- доставка из одних суточных сводок больше не отвергается целиком
- единицы не переписываются молча; счётчик считает сохранённые точки
- все выходы Fold логируются, исход пишется на переживающем отмену контексте

Четыре развилки вынесены блокерами в беклог.

docs/architecture.md

@@ -230,6 +230,18 @@ HRV); у накопительных — только `date`. Поэтому то
   безопасности, исход разбора виден в логе, в `delivery.parse_status` и в
   `/stats`, а доразобрать их можно командой `reindex`.
 
+- **413** — тело больше допустимого. Граница стоит на **распакованном**
+  потоке, а не только на сжатом: `MaxBytesReader` поверх `r.Body` ограничивает
+  то, что приехало по сети, а в память попадает то, что из этого развернулось.
+  Измерено: 400 КиБ сжатого тела давали 400 МиБ и гигабайт выделений при
+  лимите в мегабайт. Потолок степени сжатия gzip около 1030:1, так что при
+  штатных 64 МиБ речь о десятках гигабайт на запрос, и параллельные
+  складываются. Цена отказа здесь наивысшая в проекте: приём — единственное
+  место, где поток вообще существует, и доставка, не попавшая в архив, не
+  попадает в журнал. Та же граница действует при чтении тела из архива —
+  иначе тело между двумя границами принималось бы с `200`, а потом вечно
+  валилось бы при каждой пересборке.
+
 Причина такого разделения: неизвестно, шлёт ли HAE отклонённый пакет
 повторно при периоде «Since Last Sync». Если не шлёт, строгий приём означал
 бы дыру в истории. Многоуровневая синхронизация страхует тот же риск с другой
@@ -340,11 +352,11 @@ HAE. Значит для него доставки не хвост журнал
 ```
 delivery(id, received_at, automation_name, automation_id, aggregation,
          period, session_id, bytes, sha256, raw_path, parse_status, points,
-         headers)
+         headers, derived_layer)
 
-bucket(metric, layer, hour_utc, hash, points_count, first_ts, last_ts,
-       units, payload BLOB, first_delivery_id, updated_at, sealed)
-       PK (metric, layer, hour_utc)
+bucket(metric, layer, hour_utc, units, payload BLOB, content_hash, points,
+       first_ts, last_ts, first_delivery_id, sealed, created_at, updated_at)
+       PK (metric, layer, hour_utc)  WITHOUT ROWID
 
 workout(id PK, name, start_utc, end_utc, tz_offset, duration_sec,
         payload JSON, delivery_id, updated_at)