Сделать DM body opaque для сервера и улучшить fallback UI

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

@@ -71,7 +71,28 @@
 - сервер не должен расшифровывать DM;
 - ciphertext у `type=1` и `type=2` обычно разный и не обязан совпадать побайтно.
 
-### 2.3. Источник истины по пользователю
+### 2.3. Что именно знает сервер о `body`
+
+Для контентных DM (`type=1/2`) сервер в v1 должен рассматривать `body` как opaque blob:
+
+- сервер проверяет внешний контейнер `SHiNE_DM`;
+- сервер проверяет подпись;
+- сервер проверяет служебные поля envelope;
+- сервер проверяет только то, что `bodyLen > 0` и не превышает допустимый лимит;
+- сервер не обязан разбирать внутренний crypto-контейнер `body`;
+- сервер не обязан знать конкретный алгоритм шифрования `body`.
+
+Это позволяет альтернативным клиентам использовать совместимый внешний DM-envelope при собственном формате зашифрованного payload внутри `body`.
+
+Официальный UI SHiNE при приёме такого сообщения:
+
+- пытается расшифровать знакомый формат `EncryptedBody_v1_0`;
+- показывает текст сообщения при успешной расшифровке;
+- если внутренний формат не поддерживается, показывает `Формат сообщения не поддерживается`;
+- если формат понятен, но расшифровка не удалась, показывает `Не удалось расшифровать сообщение`;
+- если `body` повреждён или структурно битый, показывает `Сообщение повреждено`.
+
+### 2.4. Источник истины по пользователю
 
 Для DM-проверки сервер использует:
 
@@ -534,6 +555,7 @@ UI-следствие для клиента:
 
 - сервер не должен требовать одинаковый `encryptedBody` у `type=1` и `type=2`;
 - сервер не должен трактовать `encryptedBody` как обычный UTF-8 текст;
+- сервер не должен валидировать внутреннюю crypto-структуру `body` у контентных DM `type=1/2`;
 - DM должны реально шифроваться end-to-end;
 - удаление одного сообщения должно стать терминальным tombstone;
 - удаление всей переписки должно стать отдельным служебным событием;

Dev_Docs/Personal_Messages/Формат_DM_v1.md

@@ -164,6 +164,12 @@ Nonce/IV для `AES-GCM`.
 
 Сервер не должен трактовать это поле как UTF-8 текст и не должен пытаться расшифровывать его в обычной DM-логике.
 
+Важно:
+
+- официальный UI SHiNE сейчас использует именно `EncryptedBody_v1_0`;
+- сервер для контентных DM `type=1/2` не должен требовать, чтобы `body` обязательно был распознан как `EncryptedBody_v1_0`;
+- сервер должен хранить и пересылать `body` как opaque bytes, если внешний контейнер `SHiNE_DM` валиден.
+
 ### Точная схема для `cryptoMethod = 1`, `cryptoVersion = 0`
 
 - публичный ключ получателя для E2EE получается как стандартное преобразование `Ed25519 -> X25519`;