Document reaching a proxy that lives in another container

A proxy published as 127.0.0.1:1080 is reachable from the host and
nowhere else — not via host.docker.internal either, since loopback
publishing never leaves the host. The fix is a shared docker network and
addressing the proxy by container name, so deploy/ now carries a ready
compose.override.yml example for exactly that, parameterised by
PROXY_NETWORK.

compose.override.yml is gitignored so a local deployment tweak cannot
collide with future pulls, the way the domain edit did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -244,6 +244,19 @@ YTDLP_PROXY=socks5h://127.0.0.1:1080
 - **`127.0.0.1` внутри контейнера — это сам контейнер.** Если Psiphon или ваш SOCKS запущен на
   хосте, укажите `socks5h://host.docker.internal:1080` (эта запись в `extra_hosts` уже есть).
   Бот проверяет прокси при старте и пишет в лог понятную причину, если тот недоступен.
+- **Прокси в соседнем контейнере — подключайтесь по имени, а не через хост.** Если прокси
+  запущен в другом compose-проекте и публикует порт как `127.0.0.1:1080`, из контейнера бота он
+  недоступен вообще: публикация на loopback видна только самому хосту. Заведите общую сеть —
+  готовый пример в [deploy/compose.proxy.yml.example](deploy/compose.proxy.yml.example):
+
+  ```bash
+  docker network ls | grep psiphon
+  cp deploy/compose.proxy.yml.example compose.override.yml
+  ```
+
+  затем в `.env` — `YTDLP_PROXY=socks5h://psiphon:1080` (имя контейнера прокси) и, если сеть
+  называется иначе, `PROXY_NETWORK=<имя>`. Файл `compose.override.yml` в `.gitignore`, так что
+  обновления с ним не конфликтуют.
 - **Прокси должен слушать интерфейс, видимый контейнеру.** Даже с `host.docker.internal`
   соединение упрётся в `ECONNREFUSED`, если клиент забинден только на loopback. Проверить: