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, если файл не найден.

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`) и подставляет небезопасные дефолты из самого