feat(registries): add SME and budget imports and fix source API workflows

docs/registry-sources-ru.md

@@ -0,0 +1,93 @@
+# Реестры поддержки МСП и участников бюджетного процесса
+
+Источники обновляются администратором через существующую карточку источника или
+`POST /api/v1/parsers/run/{source_key}/`. Ответ `202` содержит идентификатор задачи,
+доступный сразу через `/api/v1/jobs/{task_id}/`. Одновременный запуск того же
+источника возвращает `409`. Автоматические расписания не добавлены.
+
+| Источник | Карточка | Ключ парсера | Группа записей | Тип записи |
+| --- | --- | --- | --- | --- |
+| Поддержка МСП | `sme-support-recipients-registry` | `fns_sme_support_recipients` | `government_support` | `sme_support_measure` |
+| Бюджетный процесс | `budget-process-registry` | `budget_ubpandnubp` | `budget_process_registry` | `budget_registry_organization` |
+
+Записи выдаются универсальными API `/api/v2/organization-source-records/` и
+`/api/v2/organization-source-records/{uid}/`. Список содержит краткий payload;
+деталь сохраняет полные массивы и исходные бюджетные блоки. Стандартные выгрузки
+CSV/XLSX/JSON содержат полный payload, включая данные за прошлые годы.
+
+## Состав организаций и счетчики
+
+Импорт связывает сведения только с существующими организациями канонического
+справочника (`directory_imported_at` заполнено). Новые организации из внешних
+реестров не создаются. Неоднозначные и конфликтующие идентификаторы не выбираются
+автоматически. Для публикации нужны наименование, ИНН, ОГРН и ОКПО организации.
+
+Карточка, список записей и dashboard `source_counts` новых источников используют
+существующий фильтр организаций ОПК. Полный импорт и стандартная выгрузка
+охватывают все сопоставленные организации справочника, включая организации вне
+ОПК. Поэтому `published_records_count` задачи и `published_count` исходного
+артефакта могут быть больше счетчика карточки. Raw, пропуски и карантин также
+учитываются отдельно.
+
+## Загрузка и публикация
+
+МСП: каталог `https://www.nalog.gov.ru/opendata/7707329152-rsmppp/` определяет
+последний ZIP формата `structure-20230615`. Архив скачивается потоково во временный
+файл; XML проверяется по сохраненной официальной XSD 4.04. Одна мера поддержки
+создает одну стабильную запись. Размеры разных единиц остаются массивом, `amount`
+содержит только рубли. Физические лица и получатели вне справочника не
+публикуются; полный исходный ZIP сохраняется как артефакт. Лимиты: ZIP 2 GiB,
+суммарный распакованный XML 64 GiB, без извлечения путей архива на диск.
+
+ZIP запрашивается диапазонами по 16 MiB; оборванное тело продолжается с последнего
+записанного байта, до трех повторов подряд. Продолжение требует совпадения
+`Content-Range`, полного размера и сильного `ETag` либо `Last-Modified`; сменившийся
+файл не склеивается с прежним. Если сервер сразу не поддерживает Range, повтор
+полного ответа начинается с нуля. Размер диапазона и число повторов задаются
+внутренними параметрами `download_registry_archive`.
+
+В официальном архиве от 15.08.2026 `КолДок=1` встречается в XML с сотнями
+документов. Полноту подтверждают CRC архива, завершенный XML и XSD, а расхождение
+этого поля сохраняется в metadata артефакта: `documents_count` — фактическое число,
+`declared_documents_count` — сумма заявленных значений,
+`document_count_mismatch_files` — число XML с расхождением.
+
+Бюджет: `https://budget.gov.ru/epbs/registry/ubpandnubp/data` обходится по страницам
+`blocks=info`. Полная деталь запрашивается и сохраняется только для сопоставленных
+организаций. Изменение количества записей или версии во время обхода,
+дублирование идентификатора и неполная страница отклоняют новый снимок.
+Неизвестные коды статуса остаются `unknown`; документированный код `2` означает
+`inactive`. Исходные поля и неизвестные непустые блоки сохраняются в detail
+`payload.upstream`, без выдуманного толкования.
+
+Новые данные сначала попадают в staging. Только завершенный и проверенный вход
+публикуется одной транзакцией, вместе с финальными статусами журнала и задачи.
+Ошибка разбора, публикации, проверки кеша до commit или финализации сохраняет
+предыдущие записи. После commit версия кеша меняется повторно, чтобы исключить
+обычное заполнение кеша старым снимком во время транзакции. Ошибка этой повторной
+инвалидации записывается в журнал, но уже опубликованные данные и успешная задача
+не откатываются: общей транзакции базы данных и кеша нет.
+Повторная доставка задачи и повторная публикация артефакта не удаляют данные.
+Существующая политика хранения артефактов не изменена.
+
+Причина отказа проверяется по `artifact_id` в `ParserSourceArtifact.metadata`:
+`error_code` содержит класс ошибки, а `rejection_reason` — ограниченный внутренний
+код проверки, например `incomplete_budget_snapshot`. Такие коды также видны в
+ошибке задачи и журнале загрузки. Тела HTTP-ответов и XML в ошибки не копируются.
+
+Перед включением на стенде нужны миграции `parsers.0034` и `organizations.0012`,
+доступ worker к официальным HTTPS-источникам и место для временного и сохраненного
+ZIP. Первый полный импорт и время его выполнения проверяются отдельно: успешное
+чтение каталога/XSD не подтверждает успешную загрузку всего реестра.
+
+## Проверенный официальный снимок
+
+13.09.2026 полностью проверен `data-20260815-structure-20230615.zip`:
+840 457 773 байта, SHA-256
+`00bc1d1ef97e1332f5e59fb04fd230f7ed0e0452ba7e90f6551d357ec891ce7a`.
+CRC всех 14 140 XML и полный проход XSD успешны: 3 344 437 документов,
+12 580 017 мер поддержки. Все 4 173 762 меры юридических лиц прошли нормализацию
+без ошибок; 8 406 255 мер физических лиц посчитаны без нормализации.
+Эта проверка не выполняла сопоставление со справочником и публикацию в рабочую
+базу. Бюджетный API проверен со стенда: JSON первой страницы и нормализация записи
+совместимы; доступность этого API с рабочей машины отличалась от серверной.