Исправить определение клиентского DM-вызова

docs/API/12_Direct_Messages_Push_Calls_API.md

@@ -152,7 +152,7 @@
 }
 ```
 
-`sourceServerLogin` необязателен для совместимости. Пока межсерверная авторизация отложена, это поле считается доверенным. Пользовательская подпись signed-блока проверяется всегда.
+`sourceServerLogin` необязателен для совместимости. Пока межсерверная авторизация отложена, это поле считается доверенным. Пользовательская подпись signed-блока проверяется всегда. Пустой `sourceServerLogin` трактуется как клиентский вызов, непустой - как peer-вызов.
 
 Успешный ответ содержит существующие `messageKey`, `baseKey` и счётчики realtime-доставки. Повтор уже сохранённой той же ревизии обрабатывается идемпотентно.
 
@@ -356,7 +356,11 @@ Pull-синхронизация событий владельца с `synced=fal
 
 Ответ содержит `messageKey`, `known` и `delivered`. `delivered=true` означает доставку хотя бы одному серверу получателя.
 
-Периодический процесс использует одно WS-соединение с peer: сначала синхронизирует настройки, затем вызывает `DmSyncBatch` до завершения страниц и ACK. Существующий `MarkAllUserSettingsUnsynced` также сбрасывает DM-флаги и возвращает `dmUpdated`; отдельной операции `MarkAllDmUnsynced` нет.
+Периодический процесс использует один логический последовательный сеанс поверх
+постоянного WSS-пула: сначала синхронизирует настройки, затем вызывает
+`DmSyncBatch` до завершения страниц и ACK. Существующий
+`MarkAllUserSettingsUnsynced` также сбрасывает DM-флаги и возвращает
+`dmUpdated`; отдельной операции `MarkAllDmUnsynced` нет.
 
 Основные ошибки межсерверных операций:
 

docs/API/16_Server_Connection_Pool_API.md

@@ -0,0 +1,105 @@
+# Межсерверное соединение и `ServerHello`
+
+Документ описывает транспортный слой постоянных WSS-соединений между серверами SHiNE.
+Он не меняет форматы DM, блоков, настроек, ACK или расписания повторных попыток.
+
+## 1. `ServerHello`
+
+После установления исходящего WSS-соединения сервер первым запросом отправляет:
+
+```json
+{
+  "op": "ServerHello",
+  "requestId": "server-hello-001",
+  "payload": {
+    "serverLogin": "shineupme",
+    "protocolVersion": 1,
+    "capabilities": [
+      "dm-sync",
+      "settings-sync",
+      "block-sync",
+      "connection-pool"
+    ]
+  }
+}
+```
+
+Успешный ответ:
+
+```json
+{
+  "op": "ServerHello",
+  "requestId": "server-hello-001",
+  "status": 200,
+  "payload": {
+    "accepted": true,
+    "serverLogin": "server2",
+    "protocolVersion": 1,
+    "capabilities": [
+      "dm-sync",
+      "settings-sync",
+      "block-sync",
+      "connection-pool"
+    ]
+  }
+}
+```
+
+На текущем этапе `serverLogin` принимается на доверии. Подпись, challenge и
+проверка корневого ключа сервера намеренно отложены. Поэтому `ServerHello`
+фиксирует тип соединения и возможности peer, но пока не является
+криптографической аутентификацией.
+
+## 2. Пул соединений
+
+- физическое соединение создаётся одно на `serverLogin`;
+- логические операции DM, settings и blockchain используют один WSS;
+- завершение `RemoteSyncSession` не закрывает физический сокет;
+- известные peer берутся из `sync_servers` и `user_access_servers_current`;
+- список перечитывается каждые 30 секунд;
+- при изменении URL соединение пересоздаётся;
+- новые запросы не повторяются транспортом автоматически: действующие
+  domain-воркеры сохраняют прежние правила retry и идемпотентности.
+
+## 3. Приоритеты
+
+| Приоритет | Операции |
+| --- | --- |
+| `REALTIME` | доставка DM, deletes, `GetDmDeliveryStatus` |
+| `NORMAL` | настройки, `DmSyncBatch` и access-data sync |
+| `BULK` | blockchain heads, blocks, `AddBlock` backfill |
+
+На одном peer одновременно исполняется один запрос. Приоритет применяется к
+ожидающей очереди и не прерывает уже начатую операцию.
+
+## 4. Ping, reconnect и таймауты
+
+Значения по умолчанию:
+
+| Параметр | Значение |
+| --- | ---: |
+| `server.pool.pingIdleSeconds` | `120` |
+| `server.pool.pongTimeoutSeconds` | `15` |
+| `server.pool.requestTimeoutSeconds` | `12` |
+| `server.pool.connectTimeoutSeconds` | `15` |
+| `server.pool.callerTimeoutSeconds` | `35` |
+| `server.pool.maxQueuePerPeer` | `2000` |
+
+Ping отправляется WebSocket control-frame только после периода отсутствия
+полезного трафика. При потере соединения применяется reconnect с jitter и
+ступенями до 60 секунд.
+
+## 5. Диагностика
+
+Внутренний snapshot пула хранит для каждого peer:
+
+- состояние соединения;
+- URL;
+- времена connect/activity/ping/pong;
+- число reconnect;
+- размеры очередей по приоритетам;
+- успешные, ошибочные и просроченные запросы;
+- последнюю ошибку.
+
+Агрегированное состояние периодически записывается в серверный лог. Отдельная
+публичная операция метрик на этом этапе не добавляется.