Persist client-side search indexes across page loads

[detournemint]

Fixes #418 (discussion in #282).

What this does

Local-files and Google Drive client search indexes now survive page reloads. The indexed documents (and, for local files, the picked directory handle) are stored in IndexedDB after each successful sync, and the Orama indexes rebuild from them on app load — no more re-picking the folder and waiting for a full re-index every visit.

• Search works immediately after restore with no prompts; the existing source-config UI lights up with the restored state.
• Local images may need a one-click re-grant: browsers require a user gesture to re-authorize a restored directory handle, so the Local Folder config shows a "Re-grant folder access" button when needed. Search is never blocked on this.
• Disconnecting a source clears its persisted data; the existing Synchronise button overwrites it (re-sync remains manual — no silent background re-walks).
• Persistence is best-effort: any storage failure logs and degrades to today's behavior. Schema-versioned so future format changes invalidate cleanly.

Implementation notes

• Documents are persisted rather than a serialized Orama database: rebuilding via insertMultiple is fast, and FileSystemFileHandles inside local-file documents are structured-cloneable (IndexedDB stores them natively; JSON serialization would destroy them).
• The Orama index construction is extracted into a small buildOramaIndex module shared by the indexer and the restore path (also makes it unit-testable — indexer.ts itself can't be loaded by Jest due to an ESM-only dependency).
• Adds fake-indexeddb as a dev dependency for tests.

Testing

• 8 Jest tests: persistence round-trip, per-source isolation, clear, schema-version mismatch invalidation, storage-failure degradation, and index rebuild from persisted documents
• Full chromium Playwright suite passes (the restore path runs on every page load in these tests)

🤖 Generated with Claude Code