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 скриптов,
приёмка прогнана против дерева.

CHANGELOG.md

@@ -14,6 +14,103 @@ Hardening-проход перед релизом `1.0.0`. Основная те
 
 ### Исправлено
 
+- **Каждая чистая установка падала сразу после `apt-get`.** Внутри `install`
+  `preflight()` вызывался дважды, и оба раза проверял контракт чистого хоста.
+  Ко второму вызову на диске уже лежал собственный
+  `/var/lib/hy2xs/install-state.json`, записанный после первого preflight, — и
+  он опознавался как маркер посторонней установки. Отказ приходил уже как
+  `fatal_post_apply`: сервер оставался наполовину настроенным, а повторный
+  запуск упирался в тот же маркер.
+
+  Причина в том, что clean-host и проверка возможностей платформы ехали одним
+  параметром, хотя отвечают на разные вопросы: чистота хоста — условие **входа**
+  в операцию, а `systemd-run`/`nftables`/OpenSSL 3 проверяются уже после
+  `installDeps`, то есть внутри PHASE 1. `preflight()` теперь принимает
+  `checkCleanHost` явно и **без значения по умолчанию** в режиме install: любое
+  умолчание здесь неверно, решение обязано приниматься на месте вызова.
+
+- **PHASE 1 начиналась вне зоны ответственности оркестратора.** `install.sh`
+  сам создавал `/usr/local/lib/hy2xs`, ставил туда бинарник, вешал symlink в
+  `/usr/local/bin` и копировал runtime-пакет — и только потом запускал
+  оркестратор, у которого дальше шёл собственный preflight. Если тот отказывал
+  (сменился DNS, занялся порт, не ответил резолвер), ни один ownership-флаг не
+  был взведён: отказ классифицировался как `fatal_pre_apply`, и оператор читал
+  «на сервере ничего не изменено» при уже созданном каталоге оркестратора.
+  Следующий запуск упирался в эти пути как в маркеры чужой установки.
+
+  Отследить владение мутацией невозможно, пока мутируют двое. Теперь
+  `install.sh` не изменяет на сервере **ничего**: он проверяет и передаёт
+  управление через `exec`. Раскладку выполняет сам оркестратор — шаг
+  `steps/bootstrap.ts` под флагом `ownership.bootstrapTouched`, а сами пути
+  попадают в `owned_paths` install-state наравне с остальными. Сборка проверяет
+  структурно, что в установщике не осталось ни одной мутирующей команды.
+
+  Побочный эффект: у списка clean-host маркеров больше нет «мягкой» версии для
+  PHASE 1. Она существовала только затем, чтобы установка не отказала на путях,
+  которые shell создал между фазами.
+
+- **Machine token утекал в обычные логи при каждом подключении пира.** Hysteria
+  обращается к машинному endpoint'у как
+  `/internal/hysteria/auth?access_token=<секрет>`, а журнал админки писал
+  `c.Request.RequestURI` — то есть путь вместе с query string. Действующий
+  токен оседал открытым текстом в `/var/log/hy2xs/hy2xs-admin.log`, который
+  отдаётся оператору через `ExportLog` и попадает в diagnostics-бандл. Вся
+  структурная редакция, сделанная для конфигов и env, этот канал не закрывала.
+
+  Логируется путь; значения query-параметров не пишутся вовсе, имена —
+  пишутся (`reqQueryKeys`). Поле `reqUri` удалено из модели журнала.
+
+  Каналов было два: `gin.Default()` подключает `gin.Logger()`, который печатает
+  путь вместе с query в stdout, откуда он уходит в journald, а оттуда — в
+  diagnostics-бандл. Панель запускается через `gin.New()` + `gin.Recovery()`,
+  и HTTP-логгер у продукта остался ровно один.
+
+  Дополнительно: журналы внутри diagnostics-бандла (`journal-admin.log`,
+  `journal-hysteria.log`, вывод `systemctl status`) больше не копируются как
+  есть, а проходят санитайз; тот же проход применяется к журналу Hysteria,
+  который админка отдаёт через `ExportLog`. Сравнение machine token переведено
+  на `subtle.ConstantTimeCompare`.
+
+- **Config API позволял прочитать и подменить криптографические ключи
+  приложения.** Generic export/import таблицы `config` удалили, но точечный API
+  остался прежним: `getConfig`/`listConfig` принимали произвольный ключ, а
+  проверка записи работала denylist'ом из трёх ключей оркестратора. Запрос
+  `?key=PEER_SECRET_ENCRYPTION_KEY` отдавал master-key шифрования секретов
+  пиров, а `updateConfigs` позволял подменить `JWT_SECRET` и оба peer-ключа.
+
+  Доступ переведён на **allowlist**: наружу открыты только
+  `HYSTERIA2_TRAFFIC_TIME`, `RESET_TRAFFIC_CRON` (чтение и запись) и
+  `HYSTERIA2_CONFIG_REMARK` (только чтение). Denylist требует, чтобы автор
+  каждого нового ключа вспомнил про этот файл; при allowlist забытый ключ
+  закрыт. Маршрут `GET /api/config/getConfig` удалён целиком — потребителей у
+  него не было ни одного, а фильтр на неиспользуемой двери остаётся дверью.
+
+- **Импорт пиров не был атомарным, вопреки собственному контракту.** Партия
+  проверялась целиком до первой записи, но применялась по одной записи, каждая
+  своим оператором. Валидация ничего не знает о том, что уже лежит в базе:
+  пусть есть `A(auth_id=aaa, name=alice1)` и `B(auth_id=bbb, name=bob123)`, а
+  файл несёт `(auth_id=aaa, name=bob123)` — поиск найдёт A по `auth_id` и
+  попытается переименовать её в `bob123`, прямо в `UNIQUE(name)`. Всё, что шло
+  в файле до конфликтной строки, оставалось применённым, и откатить это
+  оператор уже не мог.
+
+  Применение выполняется одной транзакцией (`dao.WithPeerTx`). Криптоматериал
+  считается до её открытия: digest и шифрование читают ключи из той же таблицы
+  `config`, и держать на ней открытую запись во время AES по каждой из тысяч
+  записей незачем.
+
+- **Файл импорта мог содержать хвост, который молча не применялся.**
+  `json.Decoder` читает первый документ и останавливается, поэтому файл вида
+  `[{...}]\n{"что-то":"ещё"}` принимался целиком: оператор видел «импорт
+  выполнен» и не узнавал, что применилась половина. После разбора проверяется
+  `io.EOF`.
+
+- **Отказ сбора диагностики отменял откат.** В `install` и `reconfigure`
+  `diagnosticsCollect()` стояла перед rollback обычным `await`. Она создаёт
+  каталог, копирует файлы и упаковывает tar — на заполненном диске падает сама,
+  и тогда худший сценарий отказа установки гарантированно лишался единственного
+  механизма восстановления. Диагностика — best effort, откат — обязателен.
+
 - **`fatal_pre_apply` мог означать «хост уже изменён».** `install-state.json`
   пишется сразу после успешного preflight, до установки пакетов, но
   классификация отказа его не учитывала. Падение `apt-get update` или
@@ -207,6 +304,35 @@ Hardening-проход перед релизом `1.0.0`. Основная те
   systemd-юните, перекладывавший canonical env HY2XS в имена старого H UI,
   удалён.
 
+- **Экспорт пиров разделён на два явных режима.** «Экспорт настроек» — без
+  секретов, «Резервная копия» — с ними, через подтверждение с описанием риска.
+
+  Кнопка была одна и всегда звала маршрут без `includeSecrets`, хотя
+  документация называла эту пару механизмом переноса пиров. Записи с пустым
+  секретом при импорте получают **новые** секреты, поэтому перенос обычным
+  экспортом восстанавливал пиров, но все существующие клиентские ссылки после
+  него переставали работать. Разница продуктовая, и оставлять её неявной нельзя.
+
+- **`reconfigure`/`repair` больше не классифицируют отказ по тексту ошибки.**
+  Записываемая фаза выбиралась регулярным выражением
+  `/firewall|nft|ssh port check failed/i` по сообщению — тот же приём, который
+  уже убрали из `install`. Классификация переведена на ownership-флаги, а откат
+  firewall выполняется только если эта операция его трогала.
+
+- **Список непубличных IPv4 приведён к IANA Special-Purpose Address Registry.**
+  Функция называлась «маршрутизируемый публичный IPv4», а исключения покрывали
+  только приватные диапазоны: `203.0.113.5` (TEST-NET-3 из RFC-примеров)
+  считался нормальным публичным адресом сервера. Добавлены документационные
+  (`192.0.2/24`, `198.51.100/24`, `203.0.113/24`), benchmarking (`198.18/15`),
+  6to4-anycast и IETF protocol assignments.
+
+- **Отказ DNS-резолвера отличается от отсутствия A-записи.** Любая ошибка
+  `resolve4` печаталась как «has no A-record», поэтому при сломанном
+  `/etc/resolv.conf` оператор шёл править запись, которая была на месте.
+  `ENODATA`/`ENOTFOUND`/`NXDOMAIN` — это «нет записи», всё остальное —
+  «резолвер не ответил», с отдельным текстом. Фатальны оба: без ответа
+  резолвера проверка не выполнена, а не «выполнена с замечанием».
+
 - **База админки — `hy2xs-admin.db`** вместо `h_ui.db`; reference-схема —
   `apps/docs/sql/schema.sql` вместо `h_ui_db.sql`. Совместимость сохранять не
   требуется: v1 ставится только с нуля. Историческое имя `h_ui.db` остаётся в
@@ -262,6 +388,25 @@ Hardening-проход перед релизом `1.0.0`. Основная те
 - Мёртвые строки i18n, оставшиеся от H UI: `noHttpsTip`, `defaultPassTip`,
   `hui*`, `useHysteria2Cert`, `invalidWebContext`, `mustBeInteger`.
 
+- `GET /api/config/getConfig` — точечное чтение произвольного ключа таблицы
+  `config`. Потребителей у маршрута не было ни одного, а список ключей в этой
+  таблице включает `JWT_SECRET`, `PEER_SECRET_KEY` и
+  `PEER_SECRET_ENCRYPTION_KEY`. Вместе с ним удалены `dto.ConfigDto`,
+  клиентская функция `getConfigApi` и её тип.
+
+- Compatibility-слой аккаунтов предыдущего поколения: сущность
+  `entity.LegacyAccount`, миграции `002_migrate_legacy_accounts` и
+  `003_archive_legacy_account`, а также мёртвые helpers `listSQLMigrationFiles`
+  и `envInt`. HY2XS v1 не мигрирует базу `0.x` ни при каком сценарии, и
+  clean-host контракт отказывает ещё до создания базы — живого пути, по
+  которому таблица `account` могла бы оказаться в `hy2xs-admin.db`, не
+  существует. Номера оставшихся миграций сохранены: перенумерация заставила бы
+  их примениться повторно.
+
+  В `docs/14-legacy-cleanup.md` имена предыдущего поколения остаются — там они
+  обозначают реальные объекты, которые нужно удалить с сервера. Из остальных
+  v1-доков этот словарь убран.
+
 ## [1.0.0] — 2026-08-27
 
 Первый релиз линейки `v1`.