fix: harden MCP against DB corruption crashes and orphaned workers

[stashilin]

Что чинит

Три причины нестабильности MCP-сервера, наблюдавшиеся вживую (SIGSEGV-краши, orphan-worker'ы с PPID=1, держащие mcp.lock):

1. Preflight-валидация файла БД перед kuzu::Database::new — обрезанный/битый файл теперь возвращает Err вместо нативного abort/segfault всего процесса (graph и docs store).
2. Crash recovery включает startup cwd даже при пустом registry — раньше auto-reindex был no-op.
3. Worker следит за супервизором (INFIGRAPH_SUPERVISOR_PID) и завершается после его смерти: getppid-reparent-проверка на Unix (иммунна к PID reuse), OpenProcess/WaitForSingleObject на Windows.

Ревью

4 раунда CodeRabbit CLI, все находки (2 major, 3 minor, 2 trivial) исправлены, финальный прогон чистый.

Проверено

• E2E: SIGKILL супервизора → worker вышел <8 сек; битый graph → wipe/rebuild без краша
• fmt/clippy чистые, целевые тесты зелёные (--test-threads=1 для известных параллельных флейков)
• Windows-код проверен cargo check --target x86_64-pc-windows-msvc

[murari316]

Review: hold — CI-workflow/secrets risk + unrelated scope bundled in

Thanks for tackling this — the crash-resilience mechanics themselves (DB preflight
validation, crash-recovery path inclusion, supervisor-watch) are sound engineering and
directly target invariants already documented in this repo's own CLAUDE.md. But this PR
can't be merged as-is for reasons independent of that code quality.

Blocking: CI workflow change

.github/workflows/ci.yml and .github/workflows/pages.yml add:

optimize_ci:
  uses: shilin23061991/common-actions/.github/workflows/optimize-ci.yml@main
  secrets:
    graphite_token: ${{ secrets.GRAPHITE_TOKEN }}

and gate fmt/check/build behind needs: optimize_ci + if: needs.optimize_ci.outputs.skip == 'false'.

Concerns:

• The reusable workflow lives in a personal fork (shilin23061991/common-actions), not
  an org-owned repo, and is referenced unpinned (@main) — its behavior can change after
  review/merge with no diff ever appearing in this repo's history.
• It receives secrets.GRAPHITE_TOKEN.
• If that workflow's skip output is ever 'true', the required checks (fmt, check,
  build) don't run — and a skipped required check typically still satisfies branch
  protection. That means CI could report green having validated nothing.

This needs to be dropped, or replaced with a pinned (commit-SHA), org-owned equivalent,
before anything else here can be reviewed in good faith.

Unrelated scope in the same diff

Confirmed new to this branch (not on main):

• .env.1password — references COHERE_API_KEY, KIMI_API_KEY, OLLAMA_API_KEY, VOYAGE_API_KEY
• crates/infigraph-core/src/rerank.rs (new) — Cohere Rerank integration
• crates/infigraph-core/src/embed/voyage.rs (new) — Voyage AI embedder
• crates/infigraph-core/src/review/ollama.rs changes — Ollama backend wiring
• scripts/install-local.sh, branding assets under branding-system//docs/assets/branding/

None of this relates to DB-corruption/process-supervision hardening. Please split this
into: (1) the crash-resilience fix alone, (2) the CI/tooling changes (if still wanted,
after addressing the concern above, as its own reviewable PR), (3) the new
provider integrations, as their own PR(s).

On the crash-resilience fix itself (once isolated)

Reviewed graph/store.rs/docs/store.rs (DB preflight size check), recovery.rs
(crash-recovery candidate inclusion), and lifecycle.rs (supervisor-watch) against
main and this repo's own documented invariants:

• DB preflight validation: correctly implemented, new (confirmed via git log -S on
  main), and the size floor targets the actual crash mode (gross truncation). Worth
  noting in the description that this mitigates truncation specifically, not all
  corruption — a file just over the size floor with a corrupted header past the first
  page can still reach kuzu::Database::new unmodified.
• Crash recovery + empty registry: correctly gated — every candidate path, including
  the new startup-cwd one, still requires .infigraph/ to exist before being wiped. Does
  not widen what counts as "corruption," only which already-indexed paths get considered.
• Supervisor-watch: the Unix direct-child path (getppid() reparent check) is
  genuinely PID-reuse-immune as claimed. The non-direct-child fallback and the entire
  Windows path (OpenProcess/WaitForSingleObject) are not — and the PR description
  doesn't scope that distinction. Also: the getppid()-based reparent check (the actual
  headline mechanism) and the whole Windows path have zero test coverage — only the
  process_alive primitive is tested, Unix-only. Please add a test for
  spawn_parent_monitor's reparent path, and clarify the PID-reuse-immunity claim to the
  Unix direct-child case specifically.

Recommendation: request changes. Split the PR; drop or fix the CI-workflow change;
add the missing supervisor-watch test; then this is close to mergeable.