Finalize DM docs and queue routing

docs/API/09_Operations_Index.md

@@ -62,6 +62,7 @@
 | `ReceiveIncomingMessage` | `12_Direct_Messages_Push_Calls_API.md` | прием входящего DM-блока |
 | `DeleteMessage` | `12_Direct_Messages_Push_Calls_API.md` | tombstone одного личного сообщения у обеих сторон |
 | `DeleteConversation` | `12_Direct_Messages_Push_Calls_API.md` | tombstone удаления истории переписки |
+| `GetDirectMessages` | `12_Direct_Messages_Push_Calls_API.md` | постраничная загрузка истории личного диалога |
 | `AckSessionDelivery` | `12_Direct_Messages_Push_Calls_API.md` | подтверждение доставки в сессию |
 | `CallInviteBroadcast` | `12_Direct_Messages_Push_Calls_API.md` | broadcast приглашения к звонку |
 | `CallSignalToSession` | `12_Direct_Messages_Push_Calls_API.md` | сигнал звонка в конкретную сессию |

docs/Personal_Messages/Протокол_DM_v1.md

@@ -509,6 +509,35 @@ UI-следствие для клиента:
 - после применения такого сообщения UI может оставлять в чате видимую служебную точку отсечения истории;
 - отдельное UI-действие `Удалить чат` может дополнительно спросить, нужно ли вместе с удалением контакта также отправить `DeleteConversation`.
 
+### 10.5. `GetDirectMessages`
+
+Назначение:
+
+- постранично отдавать историю одного личного диалога;
+- не вываливать весь старый backlog автоматически в момент логина;
+- отдавать клиенту только полезные chat-сообщения, без технических receipt/tombstone блоков.
+
+Правила:
+
+- начиная с 22 июля 2026 года старая история DM больше не должна автоматически пушиться клиенту сразу после входа;
+- клиент сам запрашивает первую страницу истории у нужного собеседника;
+- последующие страницы клиент запрашивает по курсору `beforeTimeMs` + `beforeMessageKey`;
+- realtime-новые сообщения по-прежнему приходят отдельно через `SignedMessageArrived`.
+
+Содержимое страницы:
+
+- сервер возвращает только контентные DM типов `1/2`;
+- read-receipt (`3/4`) и tombstone удаления (`5/6/7/8`) в историю страницы не включаются;
+- сообщения идут страницами от новых к старым;
+- лимит страницы считается по самим chat-сообщениям диалога.
+
+Поле прочтения:
+
+- для каждого контентного сообщения сервер может вернуть `readAtMs`;
+- `readAtMs` означает точное время прочтения сообщения, если оно уже известно серверу;
+- если точное время для старого сообщения неизвестно, но по более новым данным видно, что сообщение уже точно прочитано, UI может показывать его как прочитанное без точного времени;
+- read-receipt при этом остаётся отдельным DM-событием синхронизации, но в обычную историю страницы не подмешивается.
+
 ## 11. Межсерверная доставка
 
 ### 11.1. Клиентская сторона
@@ -547,9 +576,12 @@ UI-следствие для клиента:
 В ней должны сохраняться:
 
 - обычные контентные DM;
+- read-receipt DM;
 - tombstone одного сообщения;
 - tombstone удаления переписки.
 
+Для контентных сообщений в БД дополнительно должно поддерживаться серверное поле `read_at_ms`, если для этого сообщения уже было принято read-receipt событие.
+
 Сообщение об удалении одного сообщения хранится в БД и не удаляется физически, чтобы:
 
 - защищать от повторного приёма старых версий;