fix: publish providers to registry bucket

docs/help/build-and-publish.md

@@ -14,8 +14,9 @@
 ## 2. Публикация провайдера в Registry
 - Артефакты: zip, SHA256SUMS, SHA256SUMS.sig
 - Подпись: для .sig использовать бинарную detached подпись
-- Хранилище: S3 bucket terraform-registry
-- Префикс: docs/<namespace>/<name>/<version>/ для документации, отдельный префикс для бинарников по правилам registry-сервера
+- Хранилище бинарников: S3 bucket `nubes-terraform-registry`
+- Хранилище документации: S3 bucket `terraform-registry` (public)
+- Префикс: `docs/<namespace>/<name>/` для документации, `<host>/<namespace>/<name>/<version>/` для бинарников
 
 ### Канонический provider release workflow
 
@@ -23,14 +24,14 @@
 
 - Registry hostname: `tf-registry.containerk8s.services.ngcloud.ru`;
 - S3 endpoint: `https://s3.msk-1.ngcloud.ru`;
-- S3 bucket: `terraform-registry`;
+- S3 bucket: `nubes-terraform-registry`;
 - DEV namespace: `nubes-dev`;
 - Provider name: `nubes`.
 
 Для DEV version `2.0.1` полный путь бинарников:
 
 ```text
-terraform-registry/tf-registry.containerk8s.services.ngcloud.ru/nubes-dev/nubes/2.0.1/
+nubes-terraform-registry/tf-registry.containerk8s.services.ngcloud.ru/nubes-dev/nubes/2.0.1/
 ```
 
 Публикация выполняется из корня репозитория одной командой:
@@ -51,21 +52,19 @@ REQUEST_DELAY=0.05 ATTEMPTS=3 \
 
 Перед upload скрипт проверяет, что каждый constructor из resource/modifier/action-файлов присутствует в `registry.go`, затем собирает provider для `linux/amd64`, `windows/amd64` и `darwin/amd64`.
 
-### Credentials и VM
+### Разделение S3-хранилищ и Credentials
 
-S3 credentials не хранятся в `registry.env` и не должны попадать в командную строку или документацию. Источники рабочего ключа:
+В архитектуре используются **два разных бакета S3**:
 
-- локально: `secrets/.s3cfg_registry`;
-- на VM `5.172.178.213`: `/home/naeel/.mc/config.json`;
-- SSH-ключ к VM: `~/.ssh/naeel_vm_id_ed25519`.
+1. **Бинарники провайдеров:**
+   - Бакет: `nubes-terraform-registry`
+   - Права на заливку: аккаунт `1112_terraform:super` (`secrets/.s3cfg_provider`, алиас `prod-s3`)
+   - Чтение: реестр читает через встроенный аккаунт `1112_terraform:reader` (`6DDP5...`)
+2. **MkDocs-документация:**
+   - Бакет: `terraform-registry` (публичный)
+   - Права на заливку: аккаунт `1325` (`secrets/.s3cfg_registry`, алиас `registry`)
 
-VM использовалась для прежних публикаций и содержит aliases `registry`, `reg`, `tfreg` и `nubes`. Проверка bucket без вывода секретов:
-
-```bash
-mc ls registry/terraform-registry
-```
-
-Нельзя заменять bucket на `nubes-terraform-registry`: у рабочего ключа нет прав на этот bucket. Симптом ошибки — `Insufficient permissions to access this path` на стадии `mc cp`; сборка provider при этом уже может быть успешной.
+Нельзя путать эти бакеты: заливка бинарников в `terraform-registry` делает версию невидимой для реестра, а попытка залить бинарники ключом документации вызывает ошибку прав доступа (`Insufficient permissions`).
 
 ### Контроль успешной публикации
 
@@ -73,7 +72,8 @@ mc ls registry/terraform-registry
 
 1. В выводе есть `Done. Version <version> uploaded.` и exit code `0`.
 2. В `generated/<stand>/provider_build/` присутствуют ZIP, `SHA256SUMS` и `.sig`.
-3. Объекты видны в точном S3 prefix через `mc ls`.
+3. Объекты видны в точном S3 prefix через `mc ls prod-s3/nubes-terraform-registry/...`.
+4. Запрос `curl https://tf-registry.containerk8s.services.ngcloud.ru/v1/providers/<namespace>/<name>/versions` возвращает новую версию в списке.
 
 Если публикация прервалась во время `01`, повторный запуск безопасен: он только читает service specs из API и перезаписывает generated YAML. Terraform apply, modify и delete для публикации не запускаются.