Desktop: deleting a group DM removes it from the local UI but the channel survives on the relay (silent failure)

**Describe the bug**

Deleting a group DM from Buzz Desktop appears to succeed — the row disappears from the sidebar and never comes back — but the channel is still fully alive on the relay: same participants, same messages. No error is shown at any point. The user is left believing a conversation was deleted when it was not.

The underlying authorization gap is #4739: DM channels are owned by the relay's own identity and every participant is enrolled as `member`, so no principal can satisfy the delete check. The bug reported here is that Desktop does not surface that rejection — it applies the deletion to its local state anyway.

**Steps to reproduce**

1. Have a group DM with 3 participants.
2. Delete it from the Desktop UI.
3. Observe the row disappear from the sidebar, with no error.
4. Query the relay for that channel: it still returns the channel, its full member list and its full message history.

**Expected behavior**

Either the deletion propagates to the relay, or Desktop surfaces the rejection and leaves the conversation in the list. A local-only removal that looks identical to a successful delete is the worst of the three.

**Actual behavior / evidence**

Read back from the relay after the UI delete: channel present, 3 members, all messages intact.

Running the same operation through the bundled CLI, signed with a participant's key, is rejected — which is what Desktop is presumably swallowing:

```
$ buzz channels delete --channel
{"error":"relay_error","message":"relay error 400: invalid: only owner can delete group"}

$ buzz channels remove-member --channel --pubkey
{"error":"relay_error","message":"relay error 400: invalid: actor not authorized"}
```

Desktop's local state is consistent with a purely client-side removal. In `~/Library/Application Support/xyz.block.buzz.app`:

- `channel-head-cache.db` → no `channel_head` row for that channel
- `observed-unread.db` → no `channel_latest` and no `unread_membership` row for it
- `observed-unread.db` → but `observed_events` still holds rows for that channel

i.e. the listing/membership records were dropped locally while the raw events remained.

*Limits of this report:* I did not instrument the UI click itself, so I cannot show the failed request; the local-DB state is post-hoc. The relay-side result and the CLI rejections are directly measured.

**Version and platform**

- Buzz Desktop 0.5.19 (macOS 25.6.0), self-hosted relay

**Additional context**

Root cause of the rejection: #4739. Related dead end for stale agent memberships: #5754. Note that a group DM is also not listed anywhere in the sidebar once removed, so there is no way back to it from the UI even though it still exists and still receives messages.