cap total connections, and document the P2P port 8444

The daemon has always listened on 8444 and nothing published it, so every
node built from this image was outbound-only. Publishing it is now a
documented choice rather than an omission -- including the two things that
are not obvious from the config: peers are told the port from `port` in
keys.dat rather than the one you mapped it to (so only 8444:8444 works),
and the node's own address is never configured at all, because every peer
replaces the hardcoded 127.0.0.1 in the version message with the IP it
sees on the socket.

An open port needs a brake, hence BITMESSAGE_MAXTOTALCONNECTIONS. It
defaults to the PyBitmessage stock 200, so nothing changes for existing
users of the image. The key is inserted when the stock config lacks it
instead of trusting the substitution: the PyBitmessage clone is unpinned,
and a silent no-op would ship a node that looks capped and is not.

The API port in the example compose moves to loopback, which is what the
README already prescribed.

README.ru-RU.md

@@ -14,8 +14,11 @@
 
 Ниже — примеры, с которых удобно начать создание контейнера.
 
-XML-RPC API полностью управляет демоном и не имеет TLS. Задайте свои учётные
-данные и оставьте порт на loopback.
+У контейнера два порта, и они не взаимозаменяемы. **8442** — XML-RPC API: он
+полностью управляет демоном и не имеет TLS, поэтому задайте свои учётные данные
+и оставьте его на loopback. **8444** — P2P-порт Bitmessage: опубликуйте его,
+чтобы к узлу могли подключаться другие, или не публикуйте, и тогда узел работает
+только на исходящих. Внутри контейнера демон слушает оба в любом случае.
 
 ## docker-compose
 
@@ -33,8 +36,10 @@ services:
       - BITMESSAGE_SEED_ADDRESSES=1
       - BITMESSAGE_TTL=172800
       - BITMESSAGE_STOPRESENDINGAFTERXDAYS=60
+      - BITMESSAGE_MAXTOTALCONNECTIONS=40
     ports:
-      - 127.0.0.1:8442:8442
+      - 127.0.0.1:8442:8442   # API — только loopback
+      - 8444:8444             # P2P — уберите строку, чтобы остаться на исходящих
     volumes:
       - bitmessage:/home/bitmessage
 
@@ -52,7 +57,9 @@ docker run -d \
   -e BITMESSAGE_SEED_ADDRESSES=1 \
   -e BITMESSAGE_TTL=172800 \
   -e BITMESSAGE_STOPRESENDINGAFTERXDAYS=60 \
+  -e BITMESSAGE_MAXTOTALCONNECTIONS=40 \
   -p 127.0.0.1:8442:8442 \
+  -p 8444:8444 \
   -v bitmessage:/home/bitmessage \
   registry.bitdeals.org/bitmessage
 ```
@@ -64,6 +71,7 @@ docker run -d \
 |Параметр|Назначение|
 |:--------|:-------|
 |-p 127.0.0.1:8442|Порт API. Внутри контейнера демон всегда слушает `0.0.0.0`, поэтому доступность определяет то, что опубликовано|
+|-p 8444|P2P-порт Bitmessage. Необязательный: без него узел всё равно подключается к пирам сам, просто к нему подключиться нельзя. Публиковать только как `8444:8444` — см. «Замечания»|
 |-v /home/bitmessage|Каталог данных: `keys.dat` (личность, настройки) и `messages.dat`. Без него после каждого обновления это новый узел|
 |-e BITMESSAGE_API_USER|Пользователь XML-RPC API. По умолчанию: `bitmessage_api_user` — измените|
 |-e BITMESSAGE_API_PASSWORD|Пароль XML-RPC API. По умолчанию: `bitmessage_api_password` — измените, см. «Замечания»|
@@ -72,6 +80,7 @@ docker run -d \
 |-e BITMESSAGE_TTL|Срок жизни вновь отправляемых сообщений, в секундах. По умолчанию: `172800`|
 |-e BITMESSAGE_STOPRESENDINGAFTERXDAYS|Прекратить повторную отправку недоставленного сообщения через X дней. По умолчанию: `30`|
 |-e BITMESSAGE_APIVARIANT|Предоставляемый API: xml или json-RPC. По умолчанию: `legacy`|
+|-e BITMESSAGE_MAXTOTALCONNECTIONS|Предел одновременных соединений, входящих и исходящих вместе (`maxoutboundconnections` равен 8, то есть это значение минус 8 — запас на входящие). По умолчанию: `200`, штатное значение PyBitmessage — снижайте, если P2P-порт опубликован|
 
 # Замечания
 
@@ -84,3 +93,21 @@ docker run -d \
 - Контейнер становится здоровым, когда у демона появилось сетевое соединение,
   — на новом узле это несколько минут. Начальный период ожидания заодно
   покрывает стартовый `VACUUM` файла `messages.dat`.
+- **P2P-порт публикуется только как `8444:8444`.** Пирам демон сообщает порт из
+  собственной конфигурации (`port` в `keys.dat`), а не тот, в который вы его
+  отобразили, поэтому `8555:8444` объявляет сети порт, где никого нет. Для
+  другого порта на хосте нужен `extport` в `keys.dat`, а его этот контейнер не
+  подставляет.
+- **Свой адрес нигде не указывается.** В version-сообщении демон шлёт
+  захардкоженный `127.0.0.1`, который каждый пир отбрасывает и берёт вместо него
+  IP, увиденный на сокете, а порт — из того же сообщения. Поэтому узел с
+  опубликованным 8444 сеть находит сама, как только он подключится наружу:
+  ни IP, ни DNS-имя хоста задавать негде. Единственное исключение — скрытый
+  сервис Tor, которому нужен явный `onionhostname`.
+- **Публикация 8444 — осознанный компромисс по безопасности.** Демон работает на
+  Python 2 и уже разбирает недоверенные данные от своих исходящих пиров, так что
+  открытый порт эту поверхность не создаёт — он меняет то, *кто* может
+  подключиться, *когда* и *сколько их*. Разбор до рукопожатия становится доступен
+  кому угодно, а реальный риск — исчерпание ресурсов, а не выполнение кода.
+  Держите `BITMESSAGE_MAXTOTALCONNECTIONS` низким и ограничьте контейнер по
+  памяти и CPU.