fix(admin): закрыть обещания панели, которые продукт не выполнял

Девятый проход, по итогам приёмки v1.0.0-rc1 на живом Debian 13. Общая тема:
интерфейс обещал оператору то, что продукт умел, но до чего не доходило
управление.

Секрет пира. Подпись под полем предлагала оставить его пустым, сервер умел его
сгенерировать, и генерация была недостижима: в go-playground/validator тег
omitempty НЕ пропускает правило, если поле объявлено указателем и указатель не
nil — hasValue считает указатель на пустую строку «значением». Правило min=6
применялось к пустой строке и отказывало. Ловушка закрыта общим шагом
нормализации DTO, а не тегом на одном поле: та же ловушка ломала фильтр списка
пиров, где очищенный крестиком el-input отправляет `?name=`. Граница проходит по
каждому полю отдельно — у remark пустая строка означает «убрать пометку», у
disabled ноль означает «включён».

Отказы. Любая ошибка любого поля превращалась в слово `invalid`, а слой vo
определял код ответа СРАВНЕНИЕМ текста сообщения — тот же антипаттерн, который
запрещён панели, только на сервере. Ответ несёт errors[{code, field, message,
params}]; панель выбирает фразу по коду и подставляет причины под поля.

Сессия. Ветка «войдите заново» была недостижима дважды: сервер отвечает HTTP 200
на любой отказ, поэтому обработчик ошибок axios не вызывался, а условие в нём
проверяло code === "A0230" и поле msg, которых в этом API никогда не было.
Истёкший токен вдобавок уезжал с кодом системной ошибки.

Иконки. Контракт currentColor был объявлен в двух местах и не действовал: восемь
ассетов несли литеральный fill="#000000" на <path>, а атрибут представления
перебивает унаследованное CSS-свойство. Под это попадали все семь иконок
бокового меню на фоне #181818.

Имя пира. Два правила на одном поле противоречили друг другу (min=1 против
6-32), а копия набора символов в слое контроллеров несла неэкранированный дефис
и впускала `, - . / : ; <` — через панель проходило имя peer/name, которое
импорт того же пира отклонял. Набор символов ЛОГИНА сознательно не сужен и
закреплён тестом: он приходит из HY2XS_ADMIN_USER и оркестратором не
ограничивается.

Добавлены подпись «Разработано во Flamy» с адресом, принадлежащим приложению, и
контрактные тесты панели как обязательный шаг сборки. Их исполняет Bun, а не
vitest: jsdom не вычисляет currentColor и визуальной корректности не доказал бы,
зато vitest привёл бы в граф pnpm audit сотню транзитивных зависимостей.

docs/ разложена по слоям, 11-testing-and-acceptance.md (117 КБ) разбит на пять
частей, добавлен docs/acceptance/ с отчётом о прогоне rc1 и перечнем дефектов.
Обход документации в приёмке стал рекурсивным: плоский docs/*.md после
разнесения по каталогам совпадал бы ровно с одним файлом.

docs/architecture/05-client-and-access-scope.md

@@ -0,0 +1,60 @@
+# Client and access scope
+
+## Цель документа
+
+Зафиксировать, что клиентский delivery/access layer не является частью install baseline.
+
+## Что входит в baseline
+
+В baseline этого пакета docs входит только следующее:
+- установка Hysteria2
+- установка HY2XS admin
+- базовая настройка systemd / firewall / `hy2xs.env` / `post-install.env`
+- подготовка рабочего серверного окружения
+
+## Что не входит в baseline
+
+В baseline **не входят**:
+- Telegram-бот
+- backend выдачи профилей
+- remote profile publishing
+- deep links
+- billing / подписки / тарифные планы
+- отдельный user-access API
+
+## Что допускается как вспомогательный слой
+
+Для smoke/manual testing могут существовать:
+- тестовый клиентский конфиг
+- тестовый URI
+- отдельные примеры импортируемых клиентских артефактов
+
+Но это не делает access layer частью install baseline.
+
+## Публичный endpoint
+
+В клиентской части используется только `public_host/public_port`.
+
+В runtime-обозначениях HY2XS это эквивалентно:
+- `HY2XS_PUBLIC_HOST`
+- `HY2XS_PUBLIC_PORT`
+
+Инварианты:
+- `listen` и `public endpoint` разделены;
+- в клиентских URL не используется `0.0.0.0`;
+- проект остаётся IPv4-only.
+- если у домена есть AAAA, HY2XS его не обслуживает (IPv6 out of scope).
+
+## Почему это важно
+
+Если смешать install baseline и delivery layer, документация начинает неверно обещать лишнее:
+- будто оркестратор обязан выдавать ключи пользователям
+- будто сервер после установки автоматически включает пользовательский backend
+- будто Telegram-бот является обязательной частью системы
+
+Это неверно.
+
+## Правильная формулировка
+
+После выполнения install flow система должна быть готова как серверное окружение HY2XS.  
+Как именно оператор потом выдаёт доступ клиентам — отдельный продуктовый контур и отдельная документация.