chore(deploy): render-templates.sh умеет читать другой файл значений

Путь к файлу со значениями был жёстко зашит как `<корень>/.env`. На
машине разработчика корневой `.env` держит боевые адреса
(LIVEKIT_NODE_IP/TURN_EXTERNAL_IP смотрят на прод), поэтому рендерить из
него конфиги для локального стенда нельзя, а подменить нечем — локальные
сессии дважды повторяли логику скрипта вручную через envsubst, что
означало расхождение с реальным рендером при первой же правке шаблонов.

Теперь источник значений задаётся переменной ENV_FILE:

    ENV_FILE=.env.local ./deploy/render-templates.sh

Поведение по умолчанию не меняется — тот же корневой `.env`. install.sh
свою переменную ENV_FILE не экспортирует, так что она сюда не протекает;
вызов из install.sh и рендер на сервере работают как раньше. Скрипт
дополнительно печатает, из какого файла взяты значения, и подсказывает
про ENV_FILE, если файл не найден.

deploy/render-templates.sh

@@ -9,16 +9,32 @@
 # запускайте ПЕРЕД `docker compose up` (и после каждого изменения .env,
 # влияющего на эти конфиги) — из корня репозитория:
 #   ./deploy/render-templates.sh
+#
+# Источник значений можно подменить переменной ENV_FILE:
+#   ENV_FILE=.env.local ./deploy/render-templates.sh
+# Это нужно для локальных стендов: корневой `.env` рабочего чекаута обычно
+# держит боевые значения (LIVEKIT_NODE_IP/TURN_EXTERNAL_IP смотрят на прод), и
+# рендерить конфиги из него для локального запуска нельзя. Без этой переменной
+# путь был жёстко зашит, и локальные сессии повторяли логику скрипта вручную
+# через envsubst — расхождение с реальным рендером ждало своего часа.
+# По умолчанию — как раньше, `<корень репозитория>/.env`, поэтому install.sh
+# и сервер ничего не замечают (свою переменную ENV_FILE install.sh не
+# экспортирует, так что она сюда не протекает).
 set -euo pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-ENV_FILE="$SCRIPT_DIR/../.env"
+# Относительный путь разрешаем от текущей директории вызова (`ENV_FILE=.env.local`
+# из корня репозитория), абсолютный — как есть.
+ENV_FILE="${ENV_FILE:-$SCRIPT_DIR/../.env}"
 
 if [ ! -f "$ENV_FILE" ]; then
     echo "render-templates.sh: не найден $ENV_FILE — сначала запустите ./install.sh или скопируйте .env.example в .env" >&2
+    echo "render-templates.sh: другой файл значений можно задать так: ENV_FILE=.env.local $0" >&2
     exit 1
 fi
 
+echo "[render] источник значений: $ENV_FILE"
+
 # Читаем только нужные ключи через grep/cut (НЕ `source .env`) — .env содержит
 # значения вроде `SMTP_FROM=VidConf <no-reply@vidconf.example>`, где `<` —
 # валидный литерал для docker-compose/pydantic, но невалидный bash-синтаксис

docs/deploy/DEPLOYMENT.md

@@ -191,6 +191,14 @@ chmod 600 .env   # секреты внутри — только root может
 собирает образы, поднимает `postgres`/`redis`, применяет миграции Alembic +
 seed, поднимает остальной стек (`up -d --wait`).
 
+По умолчанию `render-templates.sh` читает корневой `.env`. Другой файл
+значений задаётся переменной окружения — это нужно, когда рядом с рабочим
+`.env` (боевые адреса) поднимается локальный стенд:
+
+```bash
+ENV_FILE=.env.local ./deploy/render-templates.sh
+```
+
 **Не запускайте `docker compose` вручную без `--env-file .env`** — без него
 compose не подхватывает корневой `.env` (файл на уровень выше
 `deploy/docker-compose.yml`) и подставляет небезопасные дефолты из самого