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

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)

Start in src/server/api/search.ts, reading buildIndex() and ensureIndex(), then trace indexedVersions and indexPromise. Replace the drop-and-recreate flow with temporary-table swapping, remove reliance on /tmp/chronicle-search-ready, and ensure concurrent builds wait for one completed build. Done means concurrent search requests no longer fail during index construction.