store: при равной полноте точек побеждает пришедшая доставка

- байтовый порядок канонических форм остался тай-брейком только внутри одной
  доставки: на живом корпусе он решал 98,8% спорных координат и системно хранил
  меньшее значение, из-за чего step_count терял род и verify:archive был красным
- правило перестало быть коммутативным осознанно, поэтому порядок свёртки
  приведён к журнальному: проход воркера прекращается на отложенной доставке,
  а свёртка вне порядка журнала пишет WARN
- заведены счётчики PointsHeld и PointsErased — удержание полнотой и
  единственное направление, в котором правило теряет содержание

docs/conventions/storage.md

@@ -36,9 +36,15 @@
   элементов на проводе решает состав витрины.
 - Правило выбора между двумя версиями одних данных объявляется либо **функцией
   множества версий**, либо явно **функцией порядка журнала** — третьего
-  состояния нет. «Побеждает последняя пришедшая» третьим состоянием и является:
-  порядок свёртки порядку журнала не равен, и живая витрина расходится с
-  пересборкой молча.
+  состояния нет. «Побеждает последняя свёрнутая» третьим состоянием и является:
+  порядок свёртки сам по себе порядку журнала не равен, и живая витрина
+  расходится с пересборкой молча. Объявив правило функцией порядка журнала,
+  изменение обязано **внести плату целиком**: привести порядок свёртки к
+  журнальному (барьер на отложенной доставке), назвать остаточное окно и сделать
+  его наблюдаемым, а равенство «пересборка = приём» доказать оракулом с
+  отрицательным контролем. Так сделано для точек; у сущностей на тот же вопрос
+  отвечает хранимая позиция журнала, и её гарантия строго сильнее — критерий
+  выбора в `architecture.md`, «Разрешение столкновений».
 - Любое значение из чужого JSON, попадающее в ключ, в лог или в отчёт, имеет
   названный предел длины (имена непокрытых секций, `id` сущности).
 - **Колонка, по которой принимается необратимое решение, отличает ноль от «не