docs(arch): принцип секретов подресурсов + чем postgres отличается от mariadb

В раздел 6 (Подресурсы) добавлен подраздел про секреты, рождаемые операцией
подресурса:
- проблема: vault_secrets родителя — Computed, обновляется только в Read, поэтому
  после create_user пароль недоступен в том же apply (Invalid index);
- принцип: пароль должен быть выходом самого подресурса, не читаться из родителя;
- как привязано к данным, а не хардкодом: признак в YAML-спеке (по аналогии с
  suspend_on_destroy_default), условный блок в общем шаблоне;
- факт из спеков: postgres = пароль генерит платформа (нужен выход), mariadb =
  пароль задаёт пользователь на входе (выход не нужен).

docs/60_strategy/provider_philosophy.md

@@ -48,6 +48,42 @@ To prevent "bad applies" and incomplete infrastructure states, the provider will
 - Изменение ключевых параметров подресурса => ресурс заменяется.
 - Это соответствует возможностям API и сохраняет корректность состояния Terraform.
 
+### Секреты, рождаемые операцией подресурса (принцип и практика)
+
+**Проблема (наблюдаемая, 2026-10-01):** у части сервисов секрет (пароль пользователя
+БД) **генерируется платформой** внутри операции `create_user`, а доступен он не в
+выходе подресурса, а в `vault_secrets` **родительского инстанса**. При этом
+`vault_secrets` родителя — `Computed`-атрибут, который обновляется только в `Read`
+родителя (перечитывание облака на refresh/повторном apply), а **не** в конце
+`Create` подресурса. Следствие: внутри одного `apply` после `create_user` пароль
+нельзя прочитать — `vault_secrets["users"]` ещё пуст, и обращение к нему даёт
+`Invalid index`.
+
+**Принцип (правило для генератора):** секрет, который порождает операция
+подресурса, должен становиться **выходом самого подресурса** сразу по завершении
+его `Create`, а не читаться потребителем из родителя. Потребитель берёт пароль
+из `nubes_<svc>_<sub>.<sub>.password`, и зависимость по графу Терраформа
+автоматически разносит создание по времени.
+
+**Как это «прописано для postgres», а не хардкод в шаблоне.** В общий шаблон
+подресурса (`TOOLS/resource-generator/internal/templates/subresource.go`) НЕ
+зашивается имя сервиса. Признак «у этого подресурса-пользователя пароль
+генерируется платформой» должен приходить из **данных спека** (YAML), как уже
+сделано для `suspend_on_destroy_default` / `adopt_existing_on_create_default`
+(раздел 7). В шаблоне появится условный блок, срабатывающий только при наличии
+этого признака.
+
+**Различия сервисов (факт из спеков):**
+
+| Сервис | Пароль пользователя | Что нужно |
+|---|---|---|
+| PostgreSQL (90) | генерирует платформа → `vault_secrets["users"]` | выход пароля у `postgres_user` из Vault по завершении `create_user` |
+| MariaDB (115) | задаёт САМ пользователь (входной параметр `password` в `create_user`) | ничего — пароль уже в манифесте, `nubes_mariadb_user.x.password` |
+
+Вывод: фича «выход пароля» нужна только подресурсам, у которых `create_user`
+**не** принимает пароль на входе (то есть где он auto-generated). Хардкодить
+перечень сервисов в шаблоне запрещено — признак декларируется в YAML-спеке сервиса.
+
 ## 7. Каноничная lifecycle-логика для сервисов с suspend/resume
 
 Этот раздел обязателен для всех агентов, генераторов и разработчиков.