refactor(ops): массовая заливка — в общий конвейер вместо отдельных скриптов

Заливку Википедии и PMC я сделал отдельными скриптами мимо существующей
инфраструктуры: запуск руками через ssh, состояние в файле в /tmp, никакой
видимости. Результат предсказуем — за неделю обе умерли молча (обрыв базы на
20 008 статьях из 2 млн и таймаут сети на 85 тыс. из 100 тыс.), прогресс
потерялся, а узнали мы об этом через неделю. При том что рядом лежит готовый
механизм: parse_sources, прогоны со шкалой, журнал, кнопки, ретраи Celery.

Теперь это обычные типы источника — wikipedia_ru и pmc_bulk:

- заводятся и запускаются из админки, как OpenAlex или КиберЛенинка;
- показывают ту же шкалу, журнал и кнопку остановки;
- падение воркера больше не теряет прогресс: позиция продолжения хранится в
  parse_sources.resume_token (номер статьи в дампе / токен страницы бакета),
  повторный запуск берёт следующую порцию;
- укладываются в бюджет времени таска — заливка идёт порциями, а не одним
  многосуточным процессом.

Чего не хватало конвейеру для миллионов и что добавлено:
- парсеры отдают генератор, а не список: 2 млн статей в память не влезают;
- app/bulk_writer.py — запись пачками через COPY (21 тыс. строк/с против
  6.7 тыс. построчно) с переподключением к базе при обрыве;
- эмбеддинги при массовой заливке не диспатчатся: они на порядок медленнее и
  стали бы узким местом, вектора досчитываются отдельно (reembed_missing.py).

scripts/ops/bulk_ingest_*.py удалены — их работу делает конвейер.

Проверено на проде: оба парсера отдают документы, прогон через run_parser
завершается штатно, позиция продолжения сдвигается (300 → 600), повторный
запуск продолжает с неё.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -78,7 +78,9 @@
 - **fingerprints** — `doc_id`, `hash_value` (BIGINT, Winnowing), `position` — для L1.
 - **usage_logs** — `user_id`, `action` — учёт лимитов по тарифу.
 - **parse_sources** — задания парсеров (админка): тип, query, годы, лимит, статус,
-  `last_run_id` — ссылка на последний прогон.
+  `last_run_id` — ссылка на последний прогон, `resume_token` — позиция
+  продолжения для массовых источников (номер статьи в дампе, токен страницы
+  бакета).
 - **parse_runs** — прогоны заливки: стадия, счётчики (`target/fetched/processed/
   added/duplicates/skipped/failed`), `cancel_requested`, `heartbeat_at`, журнал
   событий (JSON). Тайминги раздельные: `started_at` — постановка в очередь,
@@ -119,10 +121,20 @@
 `app.bibliography.build_bibliography` (сортировка кириллица→латиница, нумерация,
 формат 7.1/7.0.5) → результат.
 
-**Наполнение корпуса.** админка/CLI → `index.run_parser` (OpenAlex/arXiv/PMC/
-КиберЛенинка, фильтр `is_oa`) → `index.add_document` (дедуп по `ext_id`,
-fingerprints, MinHash, эмбеддинг) → `index.enrich_full_text` (скачать OA-PDF →
-MinIO → переиндексация). Ход заливки пишется в `parse_runs` (§12).
+**Наполнение корпуса.** админка → `index.run_parser` — один конвейер для всех
+источников, со шкалой, журналом и кнопкой остановки. Внутри два пути записи:
+
+- *обычные источники* (OpenAlex/arXiv/PMC/КиберЛенинка, фильтр `is_oa`) —
+  `index.add_document` на каждый документ: дедуп по `ext_id`, fingerprints,
+  MinHash, Elasticsearch, эмбеддинг, затем `index.enrich_full_text` (скачать
+  OA-PDF → MinIO → переиндексация);
+- *массовые источники* (`wikipedia_ru`, `pmc_bulk`) — парсер отдаёт генератор,
+  запись идёт пачками через `COPY` (`app/bulk_writer.py`), позиция продолжения
+  хранится в `parse_sources.resume_token`. Эмбеддинги там не считаются: они
+  медленнее заливки на порядок и стали бы её узким местом, вектора
+  досчитываются отдельно (§12).
+
+Ход заливки в обоих случаях пишется в `parse_runs` (§12).
 Второй путь наполнения — ручная загрузка файлов админом: api сохраняет их в
 MinIO (`corpus-upload/`) → `index.ingest_upload` (извлечь текст → `add_document`,
 `source=manual_upload`). Это не проверка на плагиат: файл сразу становится

docs/INGESTION.md

@@ -62,7 +62,7 @@
 
 | Источник | Объём | Годен для массовой заливки |
 |----------|-------|----------------------------|
-| **Википедия ru** | дамп 5.6 ГБ, ~2 млн статей | **да** — `bulk_ingest_wikipedia_ru.py`, потоком без блокировок, ~919 отпечатков на статью. Требует осмысленный User-Agent, иначе 403 |
+| **Википедия ru** | дамп 5.6 ГБ, ~2 млн статей | **да** — тип источника `wikipedia_ru`, ~919 отпечатков на статью. Дамп качается заранее (Wikimedia отдаёт 403 без осмысленного User-Agent и рвёт долгие потоковые соединения) |
 | КиберЛенинка | ~3 млн статей | нет — блокирует выкачку PDF после ~130 запросов |
 | OpenAlex `language:ru` + OA | заявлено 395 410 | практически нет — по прямым `pdf_url` скачалось 2 из 10 (остальное 403 издателей), а метка языка ненадёжна: в выдаче попадаются англоязычные журналы |
 | eLIBRARY.RU (РИНЦ) | ~40 млн | только по договору, публичной выгрузки нет |
@@ -72,19 +72,36 @@
 Википедия формально не научный источник, но студенты копируют из неё чаще всего,
 а по объёму связного русского текста ей нет альтернативы среди доступного.
 
-### Массовая заливка: bulk вместо API
+### Массовые источники — тот же конвейер, что и обычные
 
 Постраничные API дают 1-2 статьи в секунду и упираются в rate limit — миллионы
-так не залить. Для объёма есть `scripts/ops/bulk_ingest_pmc.py`: открытый бакет
-`pmc-oa-opendata` (ключ не нужен) отдаёт у каждой статьи готовый извлечённый
-текст. Проверено 31.08: 100 статей, 183 090 отпечатков — 1831 на статью, то есть
-настоящая глубина, а не аннотация.
+так не залить. Для объёма есть два типа источника, которые читают дамп или
+бакет потоком:
+
+| Тип | Откуда | Особенность |
+|-----|--------|-------------|
+| `wikipedia_ru` | локальный дамп `scripts/parsers/ruwiki.xml.bz2` | позиция продолжения — номер статьи в дампе |
+| `pmc_bulk` | бакет `pmc-oa-opendata` (открыт, ключ не нужен) | позиция — токен страницы бакета; у каждой статьи готовый извлечённый текст |
+
+Заводятся и запускаются они как любой другой источник — через админку, и точно
+так же показывают шкалу, журнал и кнопку остановки. Отличия внутри:
+
+- парсер отдаёт **генератор**, а не список: миллионы статей в память не влезут;
+- запись идёт пачками через `COPY` (`worker-indexer/app/bulk_writer.py`) —
+  построчная вставка даёт 6.7 тыс. строк/с против 21 тыс. у COPY, а миллион
+  статей это ~2 млрд отпечатков;
+- **эмбеддинги при заливке не считаются**: они медленнее заливки и сделали бы её
+  узким местом. L1 и L2 работают сразу, векторы досчитываются потом
+  (`scripts/ops/reembed_missing.py`);
+- позиция продолжения хранится в `parse_sources.resume_token`, поэтому источник
+  запускается повторно до исчерпания — каждый прогон берёт следующую порцию и
+  укладывается в бюджет времени таска.
+
+Планировать объём: 1 млн статей ≈ 2 млрд отпечатков ≈ 200 ГБ в базе с индексами.
+При таком росте индексы перестают помещаться в память сервера БД — проверено на
+практике: поиск L1 деградировал с 31 мс до 484 мс, пока не увеличили RAM и
+`shared_buffers` (см. DR-HA.md).
 
-Ограничение по темпу: 0.3 статьи/с, миллион в один поток — около 40 суток.
-Скачивание тут не узкое место (12 статей/с в 12 потоков), упирается в
-последовательную обработку документа; для миллионов её надо распараллелить по
-ядрам воркера. Планировать объём: 1 млн статей ≈ 2.5 млрд отпечатков ≈ 400 ГБ
-в базе с индексами (сейчас 113 млн строк занимают 12 ГБ).
 ## Что подготовлено
 
 - **Парсер CyberLeninka починен** (`scripts/parsers/cyberleninka.py`): раньше слал GET