fix: Defer index creation on empty/insufficient tables

[tryweb]

Summary

Fixes #70

Add row count guard before attempting vector/FTS index creation to prevent noisy error messages when LanceDB tables have insufficient training data (< 256 rows for IVF/PQ indices).

Problem

When starting with an empty LanceDB table, the system produces noisy error messages:

[store] Vector index creation failed (attempt 1/3): lance error: Not supported: Creating empty vector indices with train=False is not yet implemented. Retrying in 512ms...
[store] Vector index creation failed (attempt 2/3): lance error: Not supported: Creating empty vector indices with train=False is not yet implemented. Retrying in 1045ms...
[store] Vector index creation failed (attempt 3/3): lance error: Not supported: Creating empty vector indices with train=False is not yet implemented
[store] Vector index creation failed after 3 attempts: lance error: Not supported: Creating empty vector indices with train=False is not yet implemented. Falling back to in-memory search.

Solution

• Add MIN_ROWS_FOR_INDEX = 256 constant (LanceDB IVF/PQ training requirement)
• Check table.countRows() before attempting index creation
• Silently defer with info log: [store] Deferring vector index creation: 0 rows found (need ≥ 256)
• No 3x retry errors for empty tables

Changes

File	Change
src/store.ts	+17 lines: row count guard, countRows type, MIN_ROWS_FOR_INDEX constant
test/unit/index-race-condition.test.ts	+84 lines: 6 new test cases for empty/insufficient row scenarios

Test Results

✓ createVectorIndexWithRetry: empty table defers index creation silently
✓ createVectorIndexWithRetry: insufficient rows defers index creation
✓ createVectorIndexWithRetry: sufficient rows attempts index creation
✓ createFtsIndexWithRetry: empty table defers index creation with error message
✓ createFtsIndexWithRetry: insufficient rows defers index creation
✓ All 11 existing tests still pass

Impact

Before	After
3x retry errors on empty table	Single info log, silent deferral
Scary error messages	Clear, informative message
Functional (fallback works)	Functional (same behavior, cleaner UX)

Closes #70