Clarify encrypted attachment MIME and UI contracts

doc/encrypted_attachments.md

@@ -9,8 +9,9 @@
 Android показывает зашифрованное вложение отдельной карточкой со статусом запроса
 ключа. После одобрения карточка обновляется на исходный файл, изображение, видео
 или голосовое. В интерфейс передаётся только расшифрованный путь; контейнер `.uenc`
-нельзя открыть или сохранить как готовое вложение. Цитаты и список чатов показывают
-название «Зашифрованное вложение» вместо manifest.
+нельзя открыть или сохранить как готовое вложение. До расшифровки цитата показывает
+название «Зашифрованное вложение», после — обычный preview исходного вложения.
+Список чатов сохраняет общее название зашифрованного вложения вместо manifest.
 
 Автор генерирует независимые случайные crypto_UUID и ключ AES-256 на каждую
 подготовку. Ключ записывается в локальную SQLite до шифрования. Готовый контейнер
@@ -38,6 +39,13 @@ encrypted_file_body:variable
 ```
 
 Метаданные содержат MIME в 32 байтах и сериализованный `attachment_info`.
+MIME — непустая NUL-строка длиной1..31 байт: ASCII33..126 без двойной кавычки
+и обратной косой черты. Общий `encrypted_file_validate_type` применяется в send,
+write и read; это проверка представления поля, без полного разбора MIME-грамматики.
+Send отклоняет неверное значение до создания задачи/ключа/worker, write — до файловых
+операций. Read проверяет расшифрованное аутентифицированное поле и при ошибке сохраняет
+прежние info/type. Сырые неверные строки в диагностику не выводятся.
+
 Каждая часть шифруется AES-256-CCM с тегом 16 байт и nonce 13 байт.
 Nonce метаданных использует `part=UINT64_MAX`; файл — порции 32768 байт
 с номерами от нуля. Общие примитивы находятся в `media_async/media_crypto`;
@@ -87,7 +95,8 @@ instance того же процесса остаются защищены общ
 создаёт; ручная пользовательская загрузка на таком узле запрашивает доступ.
 Сетевая классификация `peers.storage` для этого не используется.
 
-В шапке канала кнопка «Запросы расшифровки» показывает число запросов без решения.
+В шапке desktop-клиента кнопка «Запросы расшифровки» видна при наличии запросов без решения
+и показывает их число.
 Список содержит участника, вложение, дату и отдельные кнопки выдачи/отказа.
 Двойной клик переводит к исходному сообщению. После выдачи видны ожидание доставки
 и подтверждённая доставка ключа; отказ также сохраняется.
@@ -130,8 +139,12 @@ backpressure и повтором через 5 секунд; restart продол
 неверные ключ/автор/UUID/hash, подмена метаданных с пересчитанным внешним hash,
 лишние байты, alias обоих API, сохранность существующего назначения/метаданных,
 23 сценария отказов I/O с контролем fd/temp, включая ошибку после rename.
+Для MIME проверяются все256 значений первого байта, NULL и границы поля,
+восемь ранних отказов writer с сохранением файлов/output, три допустимых roundtrip
+и семь аутентифицированных некорректных wire-полей с сохранением info/type/target.
 `test_media_primitives` проверяет оба режима temp и границу durable-публикации;
-`test_attachment_send` останавливает сервис после настоящего crypto rename до completion.
+`test_attachment_send` проверяет восемь отказов MIME до ключей/worker/файлов,
+затем останавливает сервис после настоящего crypto rename до completion.
 
 `test_encrypted_attachment`: реальные A–S–B/C, скачивание с S при выключенном A,
 перезапуски автора с запросами и получателя с ключом, выдача B и отказ C,

doc/service_lifecycle.md

@@ -137,6 +137,8 @@ completion. Отказ запуска/неверные аргументы даю
 Подробные файловые контракты, 64-битные размеры и ошибки RNG описаны в `media_async.h`.
 
 Групповой crypto worker хранит один `file_io_temp` прямо в задаче вложения.
+Общий валидатор MIME не выполняет I/O: send вызывает его в uasync до создания
+задачи/ключа, файловый codec повторяет проверку в worker до открытия файлов.
 `encrypted_file_write/read` только готовят закрытый durable temp; worker публикует
 его одним rename, completion подтверждает результат в БД/UI. Отмена до completion
 не публикует сообщение; cleanup учитывает реально созданные/заменённые файлы.