[teddytennant]

Fixes #78

LanceDBVectorStoreBackend built its Tantivy full text index once, on the first insert, and skipped it afterwards. Tantivy indexes are snapshots, so every entry added by a later insert was stored and visible to semantic and structured search but never returned by keyword_search. Since ingestion writes one batch per window, anything past the first window was affected. A table reopened in a new process had the same gap.

Changes:

• insert() now only marks the index stale (local storage only).
• keyword_search() rebuilds the index before querying when it is stale or missing. Rebuilding lazily means ingestion doesn't pay for a rebuild on every window.
• The index build and the query run under a lock, since the retriever searches from a thread pool.
• Cloud storage keeps building the native index once. I checked locally that the native index also searches rows added after it was created, but I couldn't test an actual gs:// or s3:// backend.

Tests added in tests/test_vector_store_backend.py cover entries from later inserts, reopening an existing table, clear() followed by inserts, and that rebuilds happen at search time rather than insert time. The first two and the lazy-rebuild test fail on main.

Notes:

• FTS needs pylance installed alongside lancedb. Without it, index creation is skipped silently and keyword search returns nothing. I didn't touch requirements.txt.
• The first keyword search after new inserts rebuilds the index, which grows with table size (about 0.15s up to ~6k rows in my timing). If you'd rather move local storage to the native index, that would change scoring and tokenization, so I left it out of this PR.
• The same one-shot _fts_initialized pattern exists in cross/storage_lancedb.py and the two simplemem-skill copies of vector_store.py. I kept this PR focused on the core backend and can follow up on those.