fix: zilliztech/claude-context#419

[Zewang0217]

Summary

Fixes the sync-from-cloud "recovery" logic in syncIndexedCodebasesFromCloud() force-marking an in-progress indexing run as completed, silently truncating the index to whatever partial batch count happened to exist in Milvus at the time.

The guard at packages/mcp/src/handlers.ts:299 skips recovery for any codebase whose local snapshot status is indexing, leaving the real run to finish normally.

Why this fixes it

The recovery loop only checked whether a cloud collection was missing from getIndexedCodebases(). A codebase that's actively indexing is tracked separately (status indexing), so it's not in that indexed set — but its partial chunk batches are already in Milvus, since chunks flush to the DB in EMBEDDING_BATCH_SIZE-sized batches as the background task progresses. The recovery branch saw "cloud has rows, not locally indexed" and adopted the collection as completed using whatever row count existed at that instant.

That made indexing of large codebases report "✅ fully indexed" after only the first batch or two, at a nondeterministic truncation point (we observed 100, 200, and 400 files marked complete on the same ~2,600-file codebase), with no error and no indexfailed status to signal the corruption.

Verification

• Added packages/mcp/src/handlers.sync-cloud.test.ts with two cases:
  • Recovery skips codebases currently indexing — a codebase seeded as indexing with partial rows in Milvus stays indexing after sync; it's not added to the indexed list.
  • Recovery still adopts untracked codebases — a collection with no local snapshot entry at all is still recovered, preserving the intended cloud-recovery behavior (and the Snapshot 0/0 entries create infinite force-reindex loop #295 empty-row-count guard).
• Full mcp test suite passes: node --import tsx --test "src/**/*.test.ts" → 8/8 tests green.

Implementation details

A single early continue in the recovery loop when snapshotManager.getCodebaseStatus(cloudCodebase) === 'indexing'. The change is intentionally narrow — it only excludes codebases the server already knows are mid-run, so genuinely unknown collections (the legitimate recovery case) are unaffected.

Closes #419.