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/04-admin-panel.md

@@ -66,18 +66,20 @@ HY2XS admin работает как надстройка над Hysteria YAML/AP
 | Маршрут панели | всегда `/` |
 | TLS | терминируется снаружи (SSH-туннель или reverse proxy) |
 
-До v1 эти величины дублировались в таблице `config` под ключами
-`H_UI_WEB_PORT`, `H_UI_WEB_CONTEXT`, `H_UI_CRT_PATH`, `H_UI_KEY_PATH` —
-наследие H UI, где панель публиковалась наружу самостоятельно. Получался круг:
-оркестратор передавал порт аргументом, панель записывала его в SQLite и тут же
-читала обратно, а UI показывал поля в disabled-виде. Ни одного факта база при
-этом не добавляла.
+До v1 эти величины дублировались в таблице `config` собственными ключами
+панели: оркестратор передавал порт аргументом, панель записывала его в SQLite и
+тут же читала обратно, а UI показывал поля в disabled-виде. Ни одного факта база
+при этом не добавляла — это был второй источник истины без содержания.
 
-В v1 этих ключей нет ни в схеме, ни в seed, ни в интерфейсе. Собственного
+В v1 таких ключей нет ни в схеме, ни в seed, ни в интерфейсе. Собственного
 TLS-слоя у панели тоже нет: production-контракт — `HY2XS_UI_BIND_HOST=127.0.0.1`
 и `HY2XS_UI_PUBLIC_ACCESS=false`, то есть внутренний сервис. Если панели
 когда-нибудь понадобится публичный endpoint, TLS обязан заканчиваться на
-ingress/reverse-proxy, а не возвращаться к модели H UI.
+ingress/reverse-proxy, а не возвращаться к модели «панель публикует себя сама».
+
+Имена ключей предыдущего поколения намеренно не приводятся: в обычных v1-доках
+их словаря нет. Всё, что нужно для распознавания и удаления старой установки, —
+в [14-legacy-cleanup.md](14-legacy-cleanup.md).
 
 ## Пространства имён HTTP API
 
@@ -90,7 +92,7 @@ ingress/reverse-proxy, а не возвращаться к модели H UI.
 Разделение отражает разницу в природе маршрутов. `/internal/hysteria/auth` —
 не интерфейс для человека и не часть операторского API: это внутренний
 IPC-подобный HTTP endpoint между двумя процессами на одной машине. До v1 он
-лежал под тем же префиксом `hui`, что и JWT-защищённый админский API, хотя
+лежал под тем же префиксом, что и JWT-защищённый админский API, хотя
 middleware у них не пересекаются.
 
 Путь machine-auth — **runtime-контракт продукта**: он записывается в
@@ -99,11 +101,43 @@ middleware у них не пересекаются.
 `HYSTERIA_MACHINE_AUTH_PATH` в оркестраторе, — а сборка сверяет их между собой
 и с шаблонами.
 
+## Журнал запросов не содержит значений query-параметров
+
+Hysteria обращается к машинному endpoint'у как
+`/internal/hysteria/auth?access_token=<machine token>` — при каждом подключении
+пира. Поэтому в журнале админки пишется **путь**, а не `RequestURI`:
+
+```json
+{ "reqMethod": "POST", "reqPath": "/internal/hysteria/auth", "reqQueryKeys": "access_token" }
+```
+
+Пока логировался `RequestURI`, действующий machine token оседал открытым
+текстом в `/var/log/hy2xs/hy2xs-admin.log`. Этот файл отдаётся оператору через
+`ExportLog` и попадает в diagnostics-бандл, то есть секрет утекал наружу в
+штатном режиме работы — мимо всей структурной редакции, сделанной для конфигов
+и env.
+
+Значения query-параметров не логируются вовсе: список «что можно» пришлось бы
+вести вручную, и он неизбежно разошёлся бы с набором маршрутов. Имена
+параметров сохранены — для диагностики их достаточно.
+
+Каналов журналирования у панели ровно один. Админка запускается через
+`gin.New()` + `gin.Recovery()`, а не `gin.Default()`: штатный `gin.Logger()`
+печатает путь **вместе с query string** в stdout, откуда он уходит в journald, а
+оттуда — в diagnostics-бандл. Это был второй, независимый канал той же утечки, и
+починка собственного логгера его бы не закрыла.
+
+Журнал Hysteria (`ExportLog`, вкладка логов) проходит через санитайз
+`service.SanitizeLogText`: `HY2_AUTH_URL` несёт `access_token`, и upstream волен
+упомянуть его в сообщении об ошибке обращения к auth-backend. Санитайз
+сохраняет host, port и path — диагностика от него не страдает. Тот же проход
+применяется к `journal-*.log` внутри diagnostics-бандла оркестратора.
+
 ## Импорт и экспорт
 
 | Операция | Статус |
 | --- | --- |
-| Экспорт пиров (`POST /api/peer-export`) | есть |
+| Экспорт пиров (`POST /api/peer-export`) | есть, в двух режимах |
 | Импорт пиров (`POST /api/peer-import`) | есть |
 | Экспорт конфига Hysteria (`POST /api/config/exportHysteria2Config`) | есть, с вырезанием секретов |
 | Экспорт/импорт таблицы `config` | **удалён** |
@@ -118,21 +152,91 @@ Hysteria YAML. В той же таблице лежат `JWT_SECRET`, `PEER_SECR
 Осмысленного production-сценария у этой пары не было: конфигурацией сервера
 владеет оркестратор, перенос пиров делают `peer-import`/`peer-export`.
 
+### Точечный доступ к таблице `config` — по allowlist
+
+Удаления generic-пары оказалось недостаточно. Опасность осталась в точечном
+API: `getConfig` и `listConfig` принимали произвольный ключ, а проверка записи
+работала denylist'ом из трёх ключей оркестратора. То есть авторизованный запрос
+`?key=PEER_SECRET_ENCRYPTION_KEY` отдавал master-key шифрования секретов пиров,
+а `updateConfigs` позволял подменить `JWT_SECRET` и оба peer-ключа. Отверстие
+сменило размер, но не исчезло.
+
+В v1:
+
+| Ключ | Чтение | Запись |
+| --- | --- | --- |
+| `HYSTERIA2_TRAFFIC_TIME` | да | да |
+| `RESET_TRAFFIC_CRON` | да | да |
+| `HYSTERIA2_CONFIG_REMARK` | да | нет |
+| `HYSTERIA2_ENABLE`, `HYSTERIA2_CONFIG`, `HYSTERIA2_TRAFFIC_STATS_SECRET` | нет | нет, владелец — оркестратор |
+| `JWT_SECRET`, `PEER_SECRET_KEY`, `PEER_SECRET_ENCRYPTION_KEY` | нет | нет |
+| любой другой | нет | нет |
+
+Список — **allowlist**, и это структурное решение, а не стилистическое.
+Denylist требует, чтобы автор каждого нового ключа вспомнил про этот файл:
+забытый ключ при denylist сразу публичен, при allowlist — сразу закрыт. Отказ
+по умолчанию не зависит от внимательности.
+
+Маршрут `GET /api/config/getConfig` **удалён целиком**: потребителей у него не
+было ни одного, а фильтр на неиспользуемой двери — это по-прежнему дверь. Право
+записи `HYSTERIA2_CONFIG_REMARK` тоже убрано: панель его только отображает.
+
+Ключи оркестратора отклоняются отдельным сообщением, называющим владельца, —
+«этим значением владеет оркестратор» это другой ответ, чем «такого ключа нет»,
+и он ведёт оператора к `hy2xs-orchestrator reconfigure`.
+
 Оба оставшихся экспорта формируются **в памяти** и отдаются прямо в ответ.
 Раньше они шли через `os.Create` в `/var/lib/hy2xs-admin/export/`, и файл там
 оставался навсегда — при `?includeSecrets=true` это означало расшифрованные
 секреты пиров на диске, накапливающиеся с каждым нажатием кнопки. Каталога
 `export/` больше не существует.
 
-Импорт пиров проверяется так же строго, как обычное создание пира: те же
-правила для имени, quota, `maxDevices`, `disabled`, длины секрета. Дополнительно:
+### Экспорт пиров: два режима, а не флаг
+
+| Кнопка | Запрос | Что внутри |
+| --- | --- | --- |
+| **Экспорт настроек** | `POST /api/peer-export` | список пиров без секретов |
+| **Резервная копия** | `POST /api/peer-export?includeSecrets=true` | то же плюс действующие секреты подключения |
+
+Разница здесь продуктовая, а не техническая, и её нельзя оставлять неявной.
+Записи с пустым секретом при импорте получают **новые** секреты. То есть
+перенос обычным экспортом восстанавливает пиров, их квоты, лимиты и счётчики —
+но все существующие клиентские ссылки после него перестают работать.
+
+Раньше кнопка в панели была одна и всегда звала маршрут без `includeSecrets`,
+хотя документация называла эту пару механизмом переноса пиров. Оператор
+переносил пиров и обнаруживал, что все клиенты отвалились.
+
+Резервная копия содержит фактические учётные данные доступа к VPN в открытом
+виде, поэтому запускается только через явное подтверждение с описанием риска.
+Такой файл следует хранить как пароль и удалять после завершения переноса.
+
+### Импорт пиров
+
+Импорт проверяется так же строго, как обычное создание пира: те же правила для
+имени, quota, `maxDevices`, `disabled`, длины секрета. Дополнительно:
 
 - неизвестные поля в JSON отклоняются, а не игнорируются молча;
-- партия проверяется целиком **до** первой записи в базу — файл применяется
-  полностью или не применяется вовсе;
+- файл обязан содержать **ровно один** JSON-документ. `json.Decoder` читает
+  первый документ и останавливается, поэтому файл с хвостом принимался целиком,
+  а его вторая половина молча не применялась;
+- партия проверяется целиком **до** первой записи в базу;
+- применение идёт **одной транзакцией**;
 - пир `bootstrap-admin-peer` защищён от перезаписи: его секрет продублирован
   в `/etc/hy2xs/bootstrap-admin.secret`.
 
+Транзакция — не дублирование проверки, а закрытие другого класса отказов.
+Валидация проверяет содержимое файла и ничего не знает о том, что уже лежит в
+базе. Пусть существуют `A(auth_id=aaa, name=alice1)` и
+`B(auth_id=bbb, name=bob123)`, а файл несёт `(auth_id=aaa, name=bob123)`: поиск
+найдёт A по `auth_id` и попытается переименовать её в `bob123` — прямо в
+`UNIQUE(name)`. Пока записи применялись по одной, всё, что шло в файле до
+конфликтной строки, оставалось применённым, и откатить это оператор уже не мог.
+
+Криптоматериал (digest и шифртекст секретов) считается **до** открытия
+транзакции: эти операции читают ключи из той же таблицы `config`, и держать на
+ней открытую запись во время AES по каждой из тысяч записей незачем.
+
 ## Два слоя работы с конфигом Hysteria
 
 Это важное архитектурное разделение.