Добавить сухой прогон текста по конвейеру

POST /api/admin/check-message прогоняет текст через стоп-правила, глобальные исключения, ML и ИИ без создания карточки (PipelineWorkerService.DryRunAsync), отдаёт этапы, разбор и целевой контейнер. UI тестера в настройках переведён на новый контракт. Зафиксированы решения по вложениям (медиа-посты пропускаем).

docs/superpowers/STATUS.md

@@ -9,8 +9,9 @@
 > больше не знают о Telegram; Telegram-специфика — только в тонком адаптере приёма. Tenant-миграции
 > пересозданы с нуля (init). Добавлены extension-point `ISourceContentProvider`/`SourceContentResolver` и
 > `GET /api/cards/{id}/source`. Входящий поток источников — generic (`sources.proto`/`PushSource`,
-> `SourceIngressGrpcService`), `PushMessage` из telegram.proto удалён. Ядро: build 5 sln 0/0,
-> `Deal.Tests.Unit` **1289/1289 PASS**, telegram **125/125**, фронт `build` + `lint:i18n` зелёные.
+> `SourceIngressGrpcService`), `PushMessage` из telegram.proto удалён. Сухой прогон текста по конвейеру
+> (стоп-правила → ML → ИИ) без записи: `POST /api/admin/check-message` + UI настроек. Ядро: build 5 sln 0/0,
+> `Deal.Tests.Unit` **1298/1298 PASS**, telegram **125/125**, фронт `build` + `lint:i18n` зелёные.
 > Детали — `docs/superpowers/specs/2026-09-11-source-contract-design.md`.
 > Осталось (в backlog): `GET /api/cards/{id}/source` + `ISourceContentProvider`, выгрузка вложений
 > telegram-адаптером в Storage, `TelegramSourceContentProvider`, перенос оставшейся Telegram-специфики

docs/superpowers/specs/2026-09-11-source-attachments-вопросы.md

@@ -1,6 +1,29 @@
 # Открытые вопросы: вложения источников (media → Storage) и просмотр исходника
 
-Дата: 2026-09-11. Статус: часть требует живого внешнего контура (Telegram API) для проверки.
+Дата: 2026-09-11. Статус: решения владельца получены (см. §0).
+
+## 0. Решения владельца (2026-09-11)
+
+- **А) Медиа-посты пропускаем.** Сообщения без текста (только медиа/вложение) в систему не попадают.
+  Извлечение вложений Telegram и выгрузка их в Storage не делаются. Generic-контракт по-прежнему умеет
+  нести `DataRef` — этим смогут пользоваться другие источники (файл/диск/таблица) и ручные вложения карточки.
+- **Б) Проверка без живого Telegram** — реализуем с юнит-тестами на фейковой сессии/фейковом Storage,
+  без реального API.
+- **В)** Объяснение термина — в §1.5.
+
+## 1.5. Что такое «remote-просмотр исходника»
+
+Карточка хранит **ссылку на источник** (`SourceRef`) и **содержимое** (`SourceContent`). Содержимое попадает
+в карточку в момент приёма. «Просмотр исходника» — это возможность по кнопке догрузить/показать **оригинальное
+сообщение у источника** (то, что было в канале/письме/строке), если контент в карточке устарел или урезан.
+
+Сейчас содержимое уже отдаётся в `CardDto.content` и через `GET /api/cards/{id}/source`. Для локальных
+источников этого достаточно. Для **внешних** источников (например Telegram) данные лежат не в ядре, а в
+сервисе-владельце; чтобы их догрузить, ядру нужен провайдер `ISourceContentProvider` для `kind`, который
+ходит по gRPC к сервису-владельцу (условный RPC `ReadSource(dialogId, msgId)`) и возвращает исходный текст/медиа.
+
+Это и есть «remote-просмотр» — расширение extension-point, которое не требуется до появления реальной
+необходимости (напр. если карточки хранят урезанный текст или нужно открыть живой первоисточник).
 
 ## 1. Что уже готово (не требует решений)