docs(ods): вычитаны комментарии и документация починки раскладки

- Зачем:
  - правки #137 дважды рассказывали одно и то же: механика капкана жила и в
    storage.md, и у вставок, а цифры замеров — и в прозе, и в леджере;
    у читателя это спрашивает больше внимания, чем даёт.
- Что:
  - комментарии у вставок order_parse.sql сжаты до довода с указателем на
    storage.md; из капкана в storage.md цифры ушли в «Что проверено»;
    в ingestion.md замеры перенесены из прозы в свой раздел «Что проверено».
- Проверка:
  - рендер order_parse.sql по-прежнему делится ровно на два запроса
    (из комментария убрана точка с запятой, по которой оператор делит файл).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/architecture/storage.md

@@ -87,15 +87,14 @@ CSV-файла. Живёт он вне цепочки слоёв, в зоне `d
 Разные ключи у слоёв ставят капкан на вставке `INSERT INTO цель_dist SELECT …
 FROM источник_dist`. Заводское значение `parallel_distributed_insert_select` —
 2: если обе таблицы на одном кластере, вставка исполняется локально на каждом
-шарде, и шард пишет прямо в локальную таблицу цели, минуя её ключ шардирования.
-Строки наследуют раскладку источника, и ошибки при этом нет: расхождение видно
-только пересчётом по `hostName()` — сколько ключей встретилось больше чем на
-одном шарде. На разборе заказов так и вышло: 1189 из 1662 заказов легли
-одинаковыми строками на оба шарда, а `ReplacingMergeTree` через границу шарда их
-не схлопывает. Поэтому у такой вставки в `SETTINGS` стоит явное
-`parallel_distributed_insert_select = 0`: раскладку делает инициатор, по ключу
-цели (`sql/ods/order_parse.sql`). Правило нужно и дальше — сборки DDS тоже будут
-читать `_dist` и писать в `_dist` с другим ключом.
+шарде, минуя ключ шардирования цели. Строки наследуют раскладку источника, и
+ошибки при этом нет — расхождение видно только пересчётом ключей по
+`hostName()`. Так половина заказов и легла на оба шарда, где
+`ReplacingMergeTree` через границу шарда дубли не схлопывает (замер — «Что
+проверено», #137). Лекарство — явное `parallel_distributed_insert_select = 0`
+в `SETTINGS` такой вставки: раскладку делает инициатор, по ключу цели
+(`sql/ods/order_parse.sql`). Капкан ждёт и сборки DDS: они тоже будут читать
+`_dist` и писать в `_dist` с другим ключом.
 
 Ключи ко-локации названы заранее, потому что на них стоит политика соединений из
 раздела 6 спеки: обычное соединение разрешено только по ключу ко-локации, всё
@@ -592,9 +591,8 @@ DDL-словарь с файловым источником внутри `user_f
 на каждом шарде, `2` — `SELECT` и `INSERT` на каждом шарде; заводское — `2`.
 На живых данных видны и дефект, и починка: до правки 1189 из 1662 заказов
 лежали на обоих шардах, после явного нуля и повторного разбора того же
-`_load_id` — ни одного, каждый шард держит только свои ключи. Вершина версий
-уцелела: деловые поля `ods.order_v` сошлись с эталоном, посчитанным прямо из
-сырья.
+`_load_id` — ни одного. Вершина версий уцелела: деловые поля `ods.order_v`
+сошлись с эталоном, посчитанным прямо из сырья.
 
 **Проверка версий заказов 18 августа 2026 года (#94).** MCP Context7 подтвердил,
 что `JSONType` возвращает имя типа значения JSON, — на нём стоит проверка типов