fix(hub): stop keeping a copy of every group's file listing in the browser

`group_indexes` was an IndexedDB store holding a decrypted copy of each group's
index — every file's name, path, size, hash and uploader — written on every index
and on every delta, from three call sites.

It was the cross-group search of Phase 10b: `doSearch` read `getAllCachedIndexes`
and searched those records instead of dialling anything. On 2026-08-28 Search
began dialling the nodes, and that commit removed the reader and left the writers.
Since then the browser has gone on building a cleartext file listing that nothing
consulted, that no sign-out removed — the key database is a different one — and
that grew with every group ever opened. L7, at rest: kept code that nothing calls
does not sit still.

Drawing a group's files while its node is unreachable is the only thing such a
cache buys, and it is not wanted: a listing that cannot be opened is worse than an
honest absence. So there is nothing to read it with, and the writers go.

The store stays in the schema and is emptied instead. Dropping it needs a version
bump, a version bump is an upgrade another tab can block, and playlists share this
database — so the tidier change is the one with a failure mode. `purgeGroupIndexCache`
runs once per browser behind a flag, which clears what is already on people's
machines; a browser that refuses storage simply runs it again, which is harmless
because it is idempotent.

Three guards, each checked by reintroducing the fault: only `openDB` and the purge
may touch the store, the purge may only clear it, and the purge must actually be
called at start-up — a purge nobody calls is the same defect wearing the opposite
hat.

`test_sticky_header.py[firefox]` reports twelve setup errors in a full run here.
A Firefox instance is open on this machine, which is the trap CLAUDE.md describes;
the same twelve appear with these changes stashed, and the `[chrome]` half of the
same file, covering the same geometry, is clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 8 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 03ae77e..3aeb660 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -2504,6 +2504,14 @@ Two rules for a new application here:
   function. A copy keeps agreeing until one of them changes, and the symptom is a
   show whose episodes stream from two different nodes.
 
+**A group's index is never kept in browser storage.** The browser holds keys and
+playlists; it does not hold a copy of what a group contains. Such a cache existed,
+for a cross-group search that read it instead of dialling, and it outlived that
+search by weeks — writing a cleartext file listing that nothing read and no
+sign-out removed. Its only remaining use would be to draw a group's files while
+its node is unreachable, and that is refused on its own merits: a listing that
+cannot be opened is worse than an honest absence.
+
 **A group whose node is down is the normal case, and nothing waits for it.** A
 node is a machine in somebody's house, so with a handful of groups one of them
 is always off. Each index is drawn the moment it arrives rather than when its