build: закрыть обходы релизного гейта тестов и проверять весь граф npm

Два гейта сборки проверяли не то, что обещали.

1. pnpm audit проверял production-подграф вместо всего lock-графа.

   Гейт запускался с --prod под обоснованием «devDependencies в артефакт не
   попадают». Для frontend build tooling это неверно по существу: vite и
   rollup действительно не копируются на production-сервер как node_modules,
   но они ИСПОЛНЯЮТСЯ на build-машине, читают наши исходники и порождают тот
   самый production-бандл, который уезжает в артефакт.

   Это не гипотеза: DOM clobbering в Rollup затрагивал именно генерируемый
   бандл, и `pnpm audit --prod` его не показывал — по всему графу тот же
   прогон дал 33 предупреждения против нуля. Критерий приёмки №47 в docs/11
   формулировал «по всему графу» правильно ещё до того, как это стало правдой
   в коде.

   На текущем lock-файле полный граф на пороге high чист.

2. SKIP_TESTS позволял собрать production-артефакт без тестов.

   Переменная была описана как «аварийное отключение тестов; для
   release-сборок недопустимо». Недопустимость держалась исключительно на этой
   фразе: ни metadata, ни финальная приёмка архива не проверяли, что тесты
   запускались. То есть

       SKIP_TESTS=true ./tools/build/build.sh

   доходила до конца и выдавала обычный tarball с build_profile=production и
   dependency_security_gate=true — артефакт, по которому невозможно отличить
   проверенную сборку от непроверенной.

   Глушила она при этом не только тесты: под тем же флагом пропускались
   `tsc --noEmit` для оркестратора и `go vet` для админки, то есть проверка
   типов и статический анализ того самого кода, который уезжает в production.

   Выбран тот же строгий вариант, что уже принят для проверки зависимостей:
   обхода нет. Готовый пакет объявляет tests_gate=true в metadata, и это
   утверждение опирается на результат — обе функции прогона выставляют свой
   флаг только после успешного завершения, а write_metadata отказывается
   писать метаданные, если хотя бы один не подтверждён.

Приёмка закрепляет оба инварианта: --prod не может вернуться в гейт, SKIP_TESTS
не может вернуться ни в один модуль сборки и ни в README/docs, tests_gate=true
обязателен в metadata, а утверждение о прогоне обязано следовать за прогоном.

README.md

@@ -957,11 +957,19 @@ export GITHUB_TOKEN=<token>
 4. проходит compatibility gate: реальный бинарник Hysteria должен принять канонический конфиг HY2XS для Gecko и для Salamander;
 5. собирает orchestrator, frontend и backend, проставляя версию админки из контракта;
 6. прогоняет `go vet` и `go test` для HY2XS admin;
-7. проверяет граф зависимостей на известные уязвимости (`govulncheck ./...` и `pnpm audit --prod`);
+7. проверяет граф зависимостей на известные уязвимости (`govulncheck ./...` и `pnpm audit` по всему lock‑графу);
 8. формирует архив и прогоняет acceptance‑проверки.
 
 Любой сбой на шагах 1–7 останавливает сборку до создания пакета.
 
+Тесты и типы (шаги 2 и 6) — такой же обязательный гейт, как проверка
+зависимостей: переменной, которая их отключает, не существует. Готовый пакет
+объявляет об этом полем `tests_gate=true` в `metadata/package.env`, и это
+утверждение опирается на фактический прогон, а не на намерение.
+
+Для локальной работы обходить нечего: `bun test`, `bun x tsc --noEmit`,
+`go vet ./...` и `go test ./...` запускаются напрямую и tarball не создают.
+
 Переменные, управляющие выбором версии Hysteria:
 
 | Переменная | По умолчанию | Назначение |
@@ -983,6 +991,13 @@ export GITHUB_TOKEN=<token>
 цикл и падала на последнем шаге. Документированная операция, которую продукт сам
 же запрещает, — хуже отсутствующей.
 
+`pnpm audit` при этом проверяет **весь** lock‑граф frontend, а не только
+production‑подграф. Причина в том, что build tooling исполняется на build‑машине
+и порождает production‑бандл: уязвимость в `vite`/`rollup` уезжает в артефакт,
+хотя сами они на сервер не копируются. Ровно такой случай и был найден — DOM
+clobbering в Rollup затрагивал генерируемый бандл, а проверка по одному
+production‑подграфу его не показывала.
+
 Если advisory вышло в неудачный момент, чинится это обновлением графа
 (`apps/go.sum`, `apps/frontend/pnpm-lock.yaml`) или версии toolchain в
 `versions.env`. Для локальной работы обходить нечего: `go test ./...`,