feat(admin): честная длительность прогона + добор эмбеддингов

Разбор итогов массовой заливки показал в отладке «среднюю длительность прогона»
в 2.8 часа там, где парсинг занимал 50 секунд: started_at пишется в момент
постановки в очередь, а очередь из 173 источников разбирается часами. Теперь
момент реального старта пишется отдельно (run_started_at, миграция 006), а
схема отдаёт обе величины — сколько ждал очереди и сколько работал.

Плюс scripts/ops/reembed_missing.py: документ попадает в корпус сразу, а вектор
для L3 считает отдельная задача; когда worker-gpu или Ollama недоступны, эти
задачи теряются и документ остаётся невидимым для семантического поиска. Скрипт
находит faiss_id IS NULL и переотправляет пачками (dry-run по умолчанию) —
сейчас таких 23 101 из 177 147.

Документация: актуальные цифры корпуса, дубли при повторном прогоне, лимит
OpenAlex, и главное — гипервизор .254 зафиксирован в DR-HA как самая широкая
единая точка отказа (брокер, эмбеддинги, секреты и прокси на одном железе;
подтверждено аварией 28.08).

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

docs/DR-HA.md

@@ -55,6 +55,17 @@ Redis у нас — кэш/rate-limits/LSH-индекс (префикс `antipla
 | Векторный индекс | было | `VECTOR_BACKEND=qdrant` снимает (см. README) ✅ |
 | RabbitMQ .82 | да | мониторинг ловит падение ✅; кластер — по потребности |
 | app/ES 1.32 | да | воркеры горизонтальны; ES single-node (для BM25 не критично) |
+| Хост Proxmox .254 | **да, широкий** | митигации нет — см. ниже |
+
+**Гипервизор — самая широкая единая точка отказа.** На хосте `192.168.20.254`
+одновременно живут RabbitMQ (.82), embedding-gpu (.109), Infisical (.111) и
+CT 102 (.253) — фронтенд и реверс-прокси. Его падение снимает сразу: приём и
+обработку задач (нет брокера), эмбеддинги (нет Ollama), деплой (нет Infisical и
+Gitea) и весь публичный доступ (нет прокси) — при том что API, PostgreSQL и
+MinIO продолжают работать. Проверено на практике 2026-08-28: хост перестал
+отвечать даже на ARP, всё перечисленное отвалилось разом, данные не пострадали.
+Разнести хотя бы прокси/брокер по разным физическим хостам — самая дешёвая
+мера; пока её нет, восстановление требует физического доступа к железу.
 
 ## 6. Известный операционный риск — RabbitMQ `consumer_timeout` vs долгие таски