fix: закрыть каналы утечки секретов и сделать PHASE 1 владением оркестратора

Hardening-проход перед первой сборкой на Debian. Три из найденного не
воспроизводились ни на одном dry-run и проявились бы только на живом сервере.

Установка

* preflight внутри install вызывался дважды и оба раза проверял clean-host.
  Ко второму вызову на диске лежал собственный /var/lib/hy2xs/install-state.json,
  записанный после первого preflight, и опознавался как маркер посторонней
  установки: КАЖДАЯ чистая установка падала сразу после apt-get с
  fatal_post_apply и оставляла сервер наполовину настроенным. Чистота хоста —
  условие входа в операцию, возможности платформы проверяются уже внутри
  PHASE 1, поэтому checkCleanHost стал отдельным параметром без умолчания.

* PHASE 1 начиналась в install.sh: shell сам создавал /usr/local/lib/hy2xs,
  ставил бинарник, вешал symlink и копировал runtime-пакет, и только потом
  запускал оркестратор с его собственным preflight. Отказ того preflight
  объявлялся fatal_pre_apply — «на сервере ничего не изменено» — при уже
  созданном каталоге оркестратора. Отследить владение мутацией невозможно,
  пока мутируют двое: install.sh больше не изменяет ничего, раскладку
  выполняет steps/bootstrap.ts под ownership.bootstrapTouched, пути попали
  в owned_paths. Как следствие удалено деление clean-host на фазы.

* diagnosticsCollect стояла перед rollback обычным await в install и в
  reconfigure. На заполненном диске она падает сама и отменяла откат целиком.
  Диагностика — best effort, откат — обязателен.

* reconfigure/repair выбирали записываемую фазу отказа регулярным выражением
  по тексту ошибки. Переведено на ownership-флаги.

Секреты

* Журнал админки писал RequestURI, то есть путь вместе с query. Hysteria
  обращается к /internal/hysteria/auth?access_token=<секрет> при каждом
  подключении пира, поэтому действующий machine token оседал открытым текстом
  в hy2xs-admin.log, который отдаётся через ExportLog и попадает в
  diagnostics-бандл. Логируется путь; значения query не пишутся, имена —
  пишутся. Канала было два: gin.Default() печатает path?query в stdout,
  оттуда в journald и в тот же бандл, — панель переведена на gin.New() +
  Recovery(). Журналы внутри бандла и журнал Hysteria из ExportLog теперь
  проходят санитайз. Сравнение токена — constant time.

* Config API позволял прочитать и подменить ключи приложения: getConfig и
  listConfig принимали произвольный ключ, а проверка записи была denylist'ом
  из трёх ключей оркестратора. Запрос ?key=PEER_SECRET_ENCRYPTION_KEY отдавал
  master-key шифрования секретов пиров. Доступ переведён на allowlist, маршрут
  getConfig удалён целиком — потребителей у него не было ни одного.

Пиры

* Импорт применялся по одной записи вне транзакции, вопреки собственному
  контракту. Валидация не знает, что уже лежит в базе: cross-conflict по
  UNIQUE(name) оставлял часть файла применённой. Применение выполняется одной
  транзакцией, криптоматериал считается до её открытия.

* Файл импорта мог содержать хвостовой JSON-документ, который молча не
  применялся. После разбора проверяется io.EOF.

* Экспорт разделён на «Экспорт настроек» и «Резервная копия» с секретами и
  подтверждением: обычный экспорт выдаёт пирам новые секреты при импорте, и
  прежние клиентские ссылки после переноса переставали работать.

Сборка

* Два stale-грепа в приёмке роняли build.sh в самом конце, внутри
  verify_archive. Первый искал в smoke.ts исчезнувший литерал URL, второй
  совпадал с router_test.go, который перечисляет удалённые маршруты, потому
  что проверяет их отсутствие: добавление регрессионного теста ломало сборку.

* verify_archive требовал наличия мутирующей строки в install.sh. Инвариант
  перевёрнут: их не должно быть ни одной.

Очистка

* Удалены entity.LegacyAccount, миграции 002/003 и мёртвые хелперы
  listSQLMigrationFiles и envInt: v1 не мигрирует базу 0.x ни при каком
  сценарии. Номера оставшихся миграций сохранены. H UI-словарь убран из
  обычных доков, в docs/14 он остаётся — там это имена объектов для удаления.

* Список непубличных IPv4 приведён к IANA Special-Purpose Address Registry:
  203.0.113.5 из RFC-примеров считался публичным адресом сервера. Отказ
  резолвера отделён от отсутствия A-записи.

Проверено: bun test 233, go test 71, tsc/vue-tsc, bash -n 11 скриптов,
приёмка прогнана против дерева.

docs/08-orchestrator-spec.md

@@ -54,7 +54,7 @@
 Установка разделена на две фазы с жёсткой границей между ними:
 
 ```text
-PHASE 0 — READ ONLY
+PHASE 0 — READ ONLY                                    владелец: install.sh
   проверка прав
   sha256sum -c metadata/checksums.txt
   ./orchestrator/hy2xs-orchestrator preflight-install --package-dir <распакованный пакет>
@@ -63,11 +63,11 @@ PHASE 0 — READ ONLY
       └── валидация конфигурации
         ↓  ноль persistent writes
 PHASE 0 PASSED
-        ↓
-PHASE 1 — MUTATION
-  install -d /usr/local/lib/hy2xs
-  раскладка оркестратора и runtime-пакета
-  hy2xs-orchestrator install
+        ↓  exec
+PHASE 1 — MUTATION                                     владелец: оркестратор
+  preflight (clean-host — последний раз за операцию)
+  bootstrapRuntime: /usr/local/lib/hy2xs, symlink, runtime-пакет
+  installDeps → filesystem → UI → Hysteria → config → units → firewall → smoke
 ```
 
 Ключевые свойства:
@@ -82,6 +82,43 @@ PHASE 1 — MUTATION
   `install-state.json`**. Отказ на этом этапе означает, что на сервере не
   изменено ничего.
 
+### У мутации ровно один владелец
+
+`install.sh` не изменяет на сервере ничего. Он проверяет и делает `exec`.
+
+Раньше PHASE 1 начиналась в shell: установщик сам создавал
+`/usr/local/lib/hy2xs`, ставил туда бинарник, вешал symlink и копировал
+runtime-пакет, и только после этого запускал оркестратор, который выполнял
+собственный preflight. Между двумя фазами возникало окно: если второй preflight
+отказывал — сменился DNS, занялся порт, не ответил резолвер, — у оркестратора не
+был взведён ни один флаг владения, отказ классифицировался как
+`fatal_pre_apply`, и оператор читал «на сервере ничего не изменено». Хост при
+этом уже нёс каталог оркестратора, symlink и runtime-пакет, а следующий запуск
+упирался в них как в маркеры чужой установки.
+
+Владение мутацией невозможно отследить, пока мутируют двое. Поэтому раскладку
+выполняет шаг `steps/bootstrap.ts` под флагом `ownership.bootstrapTouched`, и
+эти пути попадают в `owned_paths` install-state наравне со всеми остальными.
+Сборка проверяет структурно, что в `install.sh` не осталось ни одной мутирующей
+команды.
+
+### clean-host проверяется до первой мутации и только там
+
+`preflight()` принимает `checkCleanHost` явно, без значения по умолчанию.
+
+Причина в том, что clean-host — условие **входа** в операцию, а проверка
+возможностей платформы (`systemd-run`, `nftables`, OpenSSL 3) выполняется уже
+после `installDeps`, то есть внутри PHASE 1. Пока обе проверки ехали одним
+параметром, `install` вызывал preflight дважды и оба раза с включённым
+clean-host. Ко второму вызову на диске лежал собственный
+`/var/lib/hy2xs/install-state.json`, записанный после первого preflight, — и он
+опознавался как маркер посторонней установки. Каждая чистая установка падала
+сразу после `apt-get`, получала `fatal_post_apply` и оставляла сервер
+наполовину настроенным.
+
+По той же причине у списка маркеров больше нет «мягкой» версии для PHASE 1:
+пути, которые раньше приходилось исключать, теперь создаются после проверки.
+
 Полный список маркеров чужой установки и порядок очистки —
 [14-legacy-cleanup.md](14-legacy-cleanup.md).