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/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