fix(tests): verify-snapshots грузит фикстурные кейсы и показывает долю непроверенного

configDir приходил только из скилл-уровневого setup (empty-config) и из ветки external, поэтому
у навыков с setup: none кейс на фикстуре до платформы не доезжал — и всё равно получал PASS.
Таких кейсов девять: пять support-edit, три meta-validate и один skd-decompile. В наборе по
умолчанию дефект не проявлялся: там у всех навыков setup: empty-config, и загрузка шла.

Теперь фикстура-конфигурация грузится как external-выгрузка, а путь «грузить нечего и спец-маршрут
не подошёл» вместо молчаливого PASS требует объявить skipPlatformVerify с причиной. skd-decompile
отнесён к standalone-навыкам: его выход — JSON-описание, грузить нечего.

Отдельно — видимость: «прошло» и «проверено платформой» больше не одно и то же число. В консоли и
в отчёте печатается, сколько кейсов реально обратилось к платформе, а сколько прошло мимо и почему
(external, standalone, ожидаемый отказ навыка, недоступная платформа); в таблице отчёта появилась
колонка «Платформа». Падения в эту долю не попадают: у них обращение было и не удалось.

Девяти кейсам проставлен пропуск с проверенной причиной. Для support-edit причина выяснялась
опытом: фикстуры содержат рукотворный Ext/ParentConfigurations.bin, и платформа отвечает «Ошибка
формата потока», тогда как настоящий bin из типовой грузится, а выгрузка без bin — тоже. Попытка
пересобрать фикстуры полноценными объектами вылечила XML, но не bin, и была откачена.

Документация: в README добавлена таблица маршрутов платформенной проверки и правила появления
configDir — раньше это знание жило только в коде, и «зелёный» отчёт не отличался от «проверенного».
В docs/1c-support-state-spec.md записано, что по описанной грамматике bin можно читать, но нельзя
собрать файл, который примет платформа.

Полный прогон verify-snapshots до и после правки даёт одинаковый состав: 461 passed, 6 failed,
30 skipped из 497 — новых падений нет. Тесты: 871/879, интеграционные 13/13.

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

tests/skills/README.md

@@ -46,6 +46,49 @@ node tests/skills/verify-snapshots.mjs --help                   # полный
 
 Перепрогоняет навык из DSL кейса и грузит результат в 1С — отлавливает случаи, когда снапшоты обновили, но платформа уже не принимает выход.
 
+#### Когда кейс доезжает до платформы
+
+Сначала — что вообще попадает в прогон: навыки из `DEFAULT_SKILLS` (без `--skill`), у которых есть
+каталог `snapshots/`, и их кейсы кроме `error-*`. Остальное молча не запускается, так что «в отчёте
+нет падений» и «всё проверено» — не одно и то же.
+
+Дальше маршрут выбирается по навыку; из кейса на него влияют только `skipPlatformVerify` и `setup`.
+`OK` в отчёте ещё не значит, что 1С что-то видела:
+
+| Условие | Что делает verify | Статус |
+|---|---|---|
+| кейс объявил `skipPlatformVerify` | ничего не запускает | `SKIP` с причиной из кейса |
+| `mxl-compile` | макет вкладывается в обработку, `epf-build` | `OK` / `FAIL` |
+| `skd-compile`, `skd-edit` | схема оборачивается во внешний отчёт, `erf-build` | `OK` / `FAIL` |
+| прочие `skd-*`, `mxl-*` (`STANDALONE_SKILLS`) | ничего: выход не конфигурация | `OK`, помечен «без платформы» |
+| `epf-init`, `erf-init` | `epf-build` по произведённому исходнику | `OK` / `FAIL` |
+| `cfe-*` (`CFE_SKILLS`) | двухэтапно: база, затем расширение | `OK` / `FAIL` |
+| `template-add`, `help-add` | EPF или конфигурация — по наличию `Configuration.xml` | `OK` / `FAIL` |
+| есть каталог конфигурации | `db-create` → `db-load-xml` → `db-update` | `OK` / `FAIL` |
+| ничего из перечисленного | — | `FAIL` с требованием объявить `skipPlatformVerify` |
+
+Каталог конфигурации (`configDir`) появляется в трёх случаях: скилл-уровневый `setup` —
+`empty-config` (именно **скилл**-уровневый, из `_skill.json`; переопределение в кейсе на это не
+влияет), навык — `cf-init`, либо кейс объявил `setup: external:` или `setup: fixture:` — для
+фикстуры дополнительно нужен `Configuration.xml` в её корне.
+
+Отдельный случай — `external:`: конфигурация есть, но грузить её бессмысленно, 1С читала бы
+собственную выгрузку типовой (~3 мин на кейс, ноль информации о навыке). Кейс проходит, но
+обращения к платформе не было.
+
+Поэтому «прошло» и «проверено платформой» — разные числа, и второе печатается отдельной строкой
+с разбивкой по причинам:
+
+```
+Results: <passed> passed, <failed> failed, <skipped> skipped out of <total>
+  из них проверено платформой: <N>; без обращения к платформе: <M>
+    • <k> — external: грузилась бы собственная выгрузка типовой
+    • <k> — standalone-навык: выход не конфигурация
+    • <k> — навык ожидаемо отказал: своего выхода нет, грузить нечего
+```
+
+Пока эта доля не названа, отчёт читается как «всё проверено», хотя платформу спрашивали не у всех.
+
 ## Гарды-инварианты
 
 Проверяют не вывод навыков, а инварианты исходников — то, что снапшотами не ловится. Навыки