handle group delete events by purging local state

docs/nip29-usage.md

@@ -353,10 +353,9 @@ reject anything it does not want.
 must carry every child tag, because a `9002` that drops one is rejected by the
 relay; the builder re-emits them from the struct.
 
-`delete_event` is a **relay** instruction only. The relay stops serving the event,
-but the local timeline keeps it: the backend does not evict the envelope or the
-message, so a deletion the relay accepted is still visible locally until the UI
-phase drops it. That is the one moderation write left incomplete (see below).
+`delete_event` sends `9005`, and once the relay accepts it the registry drops the
+target's cached envelope, evicts the row and re-reads the group, so the timeline stops
+showing it. Remote deletions are not folded in: the standing REQ does not carry `9005`.
 
 ## Pins
 
@@ -551,10 +550,8 @@ before they reach the consumer, so a replay cannot double-hydrate.
   `chat::Message` rendering lifted (or copied) out of `ChatPanel`: the data type
   is already shared, only the row rendering is not. `crates/workspace/src/panels/browse.rs`
   is the stub for browsing.
-- **`9005` delete does not touch local state.** The relay stops serving the
-  event, but the envelope and the row stay until a reload. Dropping it needs a
-  filter on the target's `d` tag plus the group's `r` cache tag, and an eviction
-  from `messages` and the id index; nothing does that today.
+- **Remote deletions are not folded in.** A `9005` from another admin never reaches the
+  standing REQ, so only our own accepted deletes evict the row.
 - **The LiveKit response shape is a guess.** The NIP names no fields, so
   `LivekitSession::parse` reads `token` (or `jwt`) and `url` (or `server_url`) and
   fails loudly on anything else. Re-check it against the relay actually targeted