perf: search index rebuild is not atomic and drops tables on concurrent requests #122

Problem

src/server/api/search.ts drops and recreates FTS tables in buildIndex() on each version init. If two requests hit the search endpoint simultaneously during index build, the second request can fail because the tables were just dropped.

The lock file mechanism (/tmp/chronicle-search-ready) is also unreliable across processes and deployments since temp files get cleaned.

Suggested Fix

• Build the new index in temporary tables, then atomically swap (rename) them
• Replace the lock file with an in-memory ready flag (already have indexedVersions set — lean on that)
• Add a mutex/promise guard so concurrent ensureIndex() calls wait for the first build to complete (partially done via indexPromise but the drop/recreate pattern still races)