fix(store): write index atomically and recover from corrupted index files

[rusel95]

Problem

Fixes #178. GOBStore.Persist wrote the index with gob.NewEncoder(file).Encode(...) directly into index.gob. Any crash, OOM-kill, or power loss mid-write left a truncated file behind, and every subsequent command failed forever with:

failed to load index: failed to decode index: unexpected EOF

There was no self-heal: the only way out was to manually delete .grepai/index.gob in the project and in every linked worktree (the watcher indexes them all). Multi-worktree setups made this a recurring, hard-to-diagnose breakage for both humans and AI agents using grepai via MCP.

Fix (two independent layers)

1. Atomic persist — the root cause. persistUnlocked now writes to a CreateTemp file in the same directory, then Sync → Close → rename over index.gob. A crash mid-write can no longer produce a truncated index; the previous good index survives any failed persist. This is the exact pattern already used by trace/store.go and rpg/store_gob.go — the main index was the only store missing it.

2. Corruption recovery — heals existing damage. If loadUnlocked fails to decode (indexes truncated by previous versions, disk issues), it quarantines the bad file to index.gob.corrupt (evidence preserved for debugging, never silently deleted), logs a loud warning with the path and the next step, and starts with an empty index so the next scan rebuilds it.

The recovery path is race-safe: Load holds only a shared flock, so two processes (the watch daemon retry loop plus a search/MCP call — the exact #178 scenario) can hit the recovery branch concurrently. The quarantine uses plain os.Rename; a loser whose rename fails with IsNotExist adopts the winner's recovery instead of resurfacing the fatal error, and can never delete the winner's .corrupt evidence. If the quarantine genuinely fails (e.g. read-only directory), the returned error now wraps both the decode and rename errors so a failed self-heal is diagnosable.

Tests

• garbage index → recovers empty, .corrupt quarantined
• realistically truncated index (torn write) → recovers, then persists/reloads cleanly
• zero-byte index (the most common artifact of the old bug) → recovers
• 8 concurrent Loads on the same corrupt index → all recover, evidence survives (-race)
• failed persist (read-only dir) → previous index survives untouched
• stale .corrupt from an earlier recovery → replaced by the newest evidence
• overwrite path leaves no index.gob.tmp-* files behind

Known limitations (intentionally out of scope)

• Read-only consumers (search, status, MCP) recover to an empty index and log a warning, but don't trigger a rebuild themselves — only the watcher rebuilds. A follow-up could suggest grepai watch in the CLI output when recovery fired.
• A decode failure caused by a transient read error (NFS hiccup, failing disk) is treated as corruption; the data is preserved in .corrupt and can be restored manually.
• Orphaned index.gob.tmp-* from a crash mid-persist are not swept on startup (same behavior as trace/store.go and rpg/store_gob.go).

🤖 Generated with Claude Code