fix: stabilize Polygon config loading and sync

DEPLOYMENT_DIAGNOSIS.md

@@ -22,11 +22,11 @@
 
 ### Относительный путь к YAML в Polygon
 
-В [loader.py](site/config/loader.py) пути заданы относительно текущей рабочей директории: по умолчанию `services`, а в `POLYGON_STANDS` обычно `services/dev`, `services/test`, `services/prod`. Фактические каталоги находятся внутри `site/services/`.
+Ранее [loader.py](site/config/loader.py) использовал пути относительно текущей рабочей директории: при запуске из корня репозитория это могло привести к поиску `<repo>/services` вместо `<repo>/site/services` и падению импорта до регистрации `/health`.
 
-Инструкция Nubes Flask (`~/HowTo/howto-flask-nubes.md`) указывает запуск `python site/app.py` из корня репозитория. Если рабочая директория процесса действительно корень репозитория, загрузчик будет искать `<repo>/services`, а не `<repo>/site/services`; импорт конфигурации упадёт с `FileNotFoundError` до старта Flask и `/health`. Если платформа меняет рабочую директорию на `site`, этот путь работает. Фактический CWD деплоя и логи пода не проверены.
+Исправление привязывает относительные значения по умолчанию и `POLYGON_STANDS` к каталогу `site/`, независимо от CWD. Регрессионные тесты импортируют полное Flask-приложение и проверяют `/health` с CWD корня репозитория и `site/`. Фактический CWD исторического деплоя и его логи не проверены, поэтому этот дефект не объявляется доказанной причиной инцидента.
 
-Этот риск может объяснить неготовность приложения после создания, но сам по себе не создаёт `NXDOMAIN`: DNS-имя проверяется до соединения с Flask.
+Этот дефект мог помешать запуску приложения, но сам по себе не создаёт `NXDOMAIN`: DNS-имя проверяется до соединения с Flask.
 
 ### Healthcheck
 
@@ -36,21 +36,21 @@
 
 `config/loader.py` перечисляет YAML только в каталогах, заданных `POLYGON_STANDS`, либо в `services/` при отсутствии этой переменной. Каждый файл открывается и разбирается один раз при импорте `config.loader`; обработчики API затем используют загруженные словари из памяти. Резервные каталоги `resources_yaml.bak-*` из `tf_provider` Polygon не сканирует.
 
-Следовательно, старый YAML может оставить устаревший сервис или параметры в ответах API и способен помешать запуску, если файл невалиден или отсутствует ожидаемый каталог. Но в коде нет основания заключать, что чтение старых YAML вызвало заметную задержку, а тем более DNS `NXDOMAIN`. Время загрузки YAML отдельно не измерялось.
+Следовательно, старый YAML может оставить устаревший сервис или параметры в ответах API и способен помешать запуску, если файл невалиден или отсутствует ожидаемый каталог. Генератор `from_stands.py` теперь удаляет YAML, отсутствующие в источнике, после полной успешной конвертации; если есть ошибки, очистка не выполняется. DEV, TEST и PROD копии были перегенерированы из текущих соответствующих каталогов `tf_provider`; fallback `services/` — из DEV. Время загрузки YAML отдельно не измерялось, и нет основания связывать чтение старых файлов с DNS `NXDOMAIN`.
 
 **Исправление прежнего ответа:** оценки размера и времени чтения YAML, а также предположение о конкретном negative-cache TTL DNS ранее были приведены без измерений и не являются установленными фактами. То, что адрес позднее открылся, доказывает только, что в момент повторной проверки он разрешался и отвечал; почему это изменилось, без DNS-диагностики и журналов Nubes неизвестно.
 
-Локальные удаления YAML в Polygon не отправлялись в Gitea и не развёртывались, поэтому сами по себе не меняли работающий сервис.
+Удаление четырёх старых копий `27_vc_vm_v2.yaml` не могло объяснить восстановление DNS: эти YAML влияют на содержимое API, а не на DNS-запись.
 
 ## Что проверить для точного диагноза
 
 1. В карточке инстанса: фактические `startupConfiguration.resourceRealm`, `accessConfiguration.domain`, `appConfiguration.gitPath`, `appConfiguration.healthPath` и `state_out.connectionUrl`.
 2. У операции `create`: список `stages`, результат каждой стадии и `errorLog`, особенно стадии DNS и запуска приложения.
-3. В логах пода: статус контейнера и traceback. Ошибка `Services directory not found: services` подтвердит проблему CWD/YAML-пути.
+3. В логах пода: статус контейнера и traceback. Для старой опубликованной версии ошибка `Services directory not found: services` указывала бы на проблему CWD/YAML-пути.
 4. В DNS: существует ли A-запись для точного `state_out.connectionUrl` и указывает ли она на ingress выбранного resource realm.
 
 ## Вывод
 
-Непосредственно `DNS_PROBE_FINISHED_NXDOMAIN` означает отсутствие разрешаемой DNS-записи для запрошенного имени. Наиболее важные проверки — сопоставить `domain` с `state_out.connectionUrl` и изучить DNS-стадию. Отдельно нужно проверить рабочую директорию процесса: текущий `loader.py` использует относительные пути и может не найти YAML при запуске из корня репозитория.
+Непосредственно `DNS_PROBE_FINISHED_NXDOMAIN` означает отсутствие разрешаемой DNS-записи для запрошенного имени. Наиболее важные проверки — сопоставить `domain` с `state_out.connectionUrl` и изучить DNS-стадию. Риск CWD/YAML-путей исправлен в коде и покрыт регрессионными тестами, но точная причина исторического инцидента остаётся неизвестной.
 
 `tf_provider` — источник истины для схемы Flask; его YAML в рамках этого анализа не менялись.