Починить межсерверную репликацию личных сообщений

Репликация личных сообщений между серверами теперь работает корректно.

docs/Blockchain/sync-between-servers.md

@@ -183,16 +183,20 @@ Full resync запускается только тогда, когда:
 
 Настройка влияет именно на этап подготовки отсутствующей локальной цепочки во время periodic sync.
 
-## 5. Возможное развитие server-to-server транспорта
+## 5. Реализованный постоянный server-to-server транспорт
 
-Этот раздел не описывает текущую DM-доставку. DM уже использует короткие one-shot WebSocket-вызовы, indexed outbox и ACK. Ниже остаётся возможное развитие постоянного транспорта и server-auth.
+Этот раздел не меняет текущую семантику DM, settings и blockchain. Он описывает
+единый постоянный WSS-транспорт, через который выполняются уже существующие операции.
 
 ### 5.1 Межсерверное соединение
 
-- Серверы устанавливают постоянное WebSocket-соединение друг с другом.
+- Серверы устанавливают постоянное исходящее WebSocket-соединение друг с другом.
 - Адрес партнёра определяется по `server_address` из его Solana PDA.
-- Аутентификация: подпись Ed25519 корневым ключом сервера (`root_key` из PDA).
-- При разрыве — переподключение с экспоненциальным backoff.
+- После подключения отправляется `ServerHello` с `serverLogin`, версией протокола и capabilities.
+- На текущем этапе `serverLogin` принимается на доверии; подпись Ed25519 корневым ключом сервера отложена.
+- При разрыве выполняется переподключение с jitter/backoff до 60 секунд.
+- После 120 секунд отсутствия полезного трафика отправляется WebSocket ping; pong ожидается 15 секунд.
+- Один физический канал переиспользуют DM, настройки и blockchain.
 
 ### 5.2 Доставка новых данных (push)
 
@@ -246,19 +250,21 @@ Full resync запускается только тогда, когда:
 | Плановый blockchain sync при старте + каждые 12 часов | ✅ Реализовано |
 | Обход Solana RPC через `sync.importUserProfileFromPartner.enabled` | ✅ Реализовано |
 | Обычный `AddBlock` через `tmp_bch`/`write_check`/`write_pending` | ✅ Реализовано |
-| Межсерверный постоянный WebSocket-канал | Нужна реализация |
+| Межсерверный постоянный WebSocket-канал | ✅ Реализован общий `ServerConnectionPool` |
 | Асинхронная доставка DM на access-серверы получателя | ✅ Реализовано |
 | Retry DM до 1 часа + UI-state | ✅ Реализовано |
 | Репликация DM на второй access-сервер по `synced` | ✅ Реализовано |
 | Read-only `GetDmDeliveryStatus` | ✅ Реализовано |
-| Push блоков блокчейна партнёрам | ✅ Реализована базовая one-shot версия |
+| Push блоков блокчейна партнёрам | ✅ Выполняется через постоянный WSS-пул |
 | Periodic backfill отсутствующего хвоста | ✅ Реализовано |
 | Разрешение рассинхрона / divergence | ✅ Реализована базовая full-resync схема во время periodic sync |
 | Startup recovery по `*.resync_pending` marker-file | ✅ Реализовано |
 | Маршрутизация DM через один/два `access_servers` | ✅ Реализовано |
 | Криптографическая server-to-server авторизация DM | Нужна реализация |
 
-Текущая версия сервера умеет синхронизацию блокчейнов и DM. Постоянные server-to-server соединения не требуются для текущей one-shot WS-реализации; отдельной будущей задачей остаётся криптографическая авторизация DM-вызовов.
+Текущая версия сервера использует постоянный WSS-пул для существующих
+server-to-server JSON-операций. Отдельной будущей задачей остаётся
+криптографическая авторизация server-to-server вызовов.
 
 Следующие отдельные шаги после текущего этапа:
 - отдельно проверить full-resync и startup-recovery на реальном тестовом прогоне после ручного удаления БД/файлов.