docs: пароль БД через vault_secrets["users"] — задокументировано, чтобы не искать

Проверено по API 2026-10-01 (pg4crud2, TEST):
GET /instances/<uid>/vault/users -> {"users":{"user4crudpg":{"password":"..."}}}.
Пароль ЕСТЬ; state.out.users — метаданные без пароля (их легко перепутать).

- README.md: строка навигации «Пароль БД / секреты Vault» + раздел «Грабли, на которые уже наступали»
  (Invalid index из-за одного apply; errorLog врёт — смотреть stages; лишний sensitive).
- docs/curated/postgres/pg_user_db.md: раздел «Пароль пользователя БД и секреты Vault» (ловушки,
  два apply, диагностика через /instanceOperations?fields=stages); исправлено утверждение «все 4 ресурса
  за один apply» — для приложений, читающих пароль, нужен второй apply.
- docs/30_registry/guides/getting-started.md: помечены устаревшие ключи adminUser/adminPass (сейчас 404).
- HISTORY/2026-10-01_...: дополнение с фактами и указанием, что первый разбор ошибся.

docs/curated/postgres/pg_user_db.md

@@ -139,3 +139,52 @@ terraform apply
 ```
 
 Все 4 ресурса за один `apply`. Terraform сам выстроит порядок: кластер → пользователь → БД → бакет.
+
+> ⚠️ **Исключение — если приложение берёт пароль БД из `vault_secrets` (как в CRUD-стенде): нужен второй `apply`.**
+> В первом создаются кластер и пользователь, во втором приложения получают уже появившийся пароль.
+> Иначе — `Invalid index ... does not identify an element in this collection value`.
+
+## Пароль пользователя БД и секреты Vault
+
+Проверено 2026-10-01 на TEST-стенде (инстанс `pg4crud2`).
+
+Пароль пользователя, созданного через `nubes_postgres_user`, платформа пишет в Vault и отдаёт в выходе
+`vault_secrets["users"]` — это **JSON-строка**:
+
+```json
+{ "<имя_пользователя>": { "password": "<пароль>" } }
+```
+
+Как брать в конфиге:
+
+```hcl
+locals {
+  pg_host = nubes_postgres.main_pg.state_out_flat["internalMaster"]
+  pg_user = nubes_postgres_user.crud_user_0.username
+  pg_pass = nonsensitive(jsondecode(nubes_postgres.main_pg.vault_secrets["users"])[local.pg_user].password)
+}
+```
+
+Проверить вручную (то же, что читает провайдер):
+
+```bash
+GET {api_endpoint}/instances/<instanceUid>/vault/users
+```
+
+### Ловушки
+
+- **`state.out.users` — это метаданные** (`role`, `rights`, `username`, `mtlsAccess`), **пароля там нет**.
+  Пароль лежит только в `vault_secrets["users"]`. Это два разных объекта, их легко перепутать.
+- Список доступных имён секретов — выход `vault_fields` (у PostgreSQL это `["users"]`).
+- Ключей `adminUser` / `adminPass` / `standbyUser` / `standbyPass` у новых инстансов **нет** — эндпоинт `/vault/<имя>` отдаёт 404. Они встречаются в старых материалах (например, в `docs/30_registry/guides/getting-started.md`).
+- ⚠️ **Нужно два `apply`**, если PG и пользователь создаются в одном прогоне, а приложения читают пароль: см. предупреждение в разделе «Запуск» выше.
+
+### Диагностика сбоя операции
+
+`errorLog` у платформы **не отражает суть**. Реальная причина — в `stages`:
+
+```bash
+GET {api_endpoint}/instanceOperations/<UID>?fields=cfsParams,errorLog,stages
+```
+
+`stages[].stageMsg` — JSON-массив пар `[заголовок, лог]`, смотреть последнюю запись. Там же `cfsParams` — фактический payload, ушедший на платформу. Разбор реального случая: `HISTORY/2026-10-01_test_crud_pg_create_failure.md`.