task: Silent index corruption / incomplete index reported as success (3 issues)

[DeusData]

Scope

Umbrella tracker for cases where indexing reports status: "indexed" / ready but the resulting graph is catastrophically incomplete (single-digit % of expected node count, or empty). The reports cluster around macOS, large Rust projects, and rapid kill/restart cycles where the previous process didn't release WAL or hash-row state cleanly.

PR #387 ("checkpoint WAL on close and startup to prevent orphan accumulation") may resolve a subset; reporters should re-test once it lands.

Sub-issues

• Indexing completes but DB is empty (all zeros) — macOS arm64 v0.6.0 #260 — Indexing completes but DB is empty (all zeros) — macOS arm64 v0.6.0
• Silent index degradation — status:"indexed" but only ~500 nodes for 72k LOC Rust codebase #333 — Silent index degradation — status:"indexed" but only ~500 nodes for 72k LOC Rust codebase
• Silent index corruption after rapid kill/restart cycles #334 — Silent index corruption after rapid kill/restart cycles

Acceptance

1. status: "indexed" is never returned when the index is materially incomplete.
2. A plausibility threshold (or comparison against a prior known-good baseline) gates the success status.
3. The recovery path is documented (or automatic) — no need for a full MCP disconnect/reconnect.
4. Concurrent writer / rapid-kill scenarios are reproducible in a test and produce either a clean re-index or a clear "needs recovery" status.

Why one task

All three reports share the same surface symptom (success reported, but the graph is materially incomplete) and likely share a root cause in WAL checkpointing / pipeline state cleanup.