fix(security): logout's search-index wipe coordinates across tabs

deleteSearchCacheDatabase() resolved after a 3 s "blocked" timeout while
another tab still held the DB, so decrypted rows could survive logout.
It now broadcasts lotus-logout first; every tab closes its handle and
refuses to reopen, then the delete proceeds. A boot with no session
re-runs the wipe once in case a race was still lost. Unit-tested.

Fixes #45

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA

src/index.tsx

@@ -17,6 +17,7 @@ import App from './app/pages/App';
 import './app/i18n';
 import { pushSessionToSW } from './sw-session';
 import { getFallbackSession } from './app/state/sessions';
+import { cleanupSearchCacheIfSignedOut } from './client/initMatrix';
 
 document.body.classList.add(configClass, varsClass);
 
@@ -51,6 +52,12 @@ if ('serviceWorker' in navigator) {
 // already exists" upload storm and E2EE breakage. Only ask for sessions worth
 // protecting (skip anonymous/landing visitors to avoid a needless Firefox
 // prompt); check persisted() first so we don't re-prompt. Best-effort.
+// [Gitea #45] If a logout's search-index wipe lost the multi-tab race (another
+// tab still held the DB), finish it now that no session exists.
+if (!getFallbackSession()) {
+  cleanupSearchCacheIfSignedOut().catch(() => undefined);
+}
+
 if (navigator.storage?.persist && getFallbackSession()) {
   navigator.storage
     .persisted()