Desktop client never subscribes to kind 1059, so spec-compliant NIP-17 DMs are accepted by the relay and silently invisible

## Summary

A NIP-17 gift-wrapped DM sent to a Buzz user is **accepted, stored, and correctly `p`-tagged by the relay** — and never appears anywhere in the desktop client. There is no error and no unread indicator; from the sender's side delivery looks successful, and from the recipient's side nothing happened.

The cause looks structural rather than a bug in handling: `1059` appears in the desktop tree **only** in the e2e test bridge (`desktop/src/testing/e2eBridge.ts`, `KIND_GIFT_WRAP`/`P_GATED_KINDS`), and in the relay's own `handlers/ingest.rs` + `handlers/event.rs`. I could find no production client path that subscribes to or unwraps kind 1059. Buzz's own DM model is channel-based instead (`channel_type='dm'`, kinds `41001`/`41010`/`41012`, `30622`), which a spec-conformant NIP-17 sender talks straight past.

This is adjacent to #4192 but distinct: that issue is the relay **rejecting** a spec-compliant wrap on the freshness window; this one is the client **ignoring** a wrap the relay accepted.

## Reproduction

Against a self-hosted relay at `desktop-v0.5.4` / relay image `ghcr.io/block/buzz@sha256:335bfc1e…`:

1. Two members of a closed relay: a sender (an automated service) and a recipient (a human on Buzz Desktop, joined via invite link).
2. Sender publishes a NIP-17 DM to the recipient's pubkey over the WebSocket wire: unsigned kind-14 rumor (with its canonical `id`) → kind-13 seal, NIP-44 v2, empty tags → kind-1059 gift wrap signed by a fresh ephemeral key, `p`-tagged to the recipient. Timestamps randomized into the past but kept inside the relay's ±900s window, per the workaround in #4192.
3. Relay answers `["OK", "", true, ""]`.
4. Confirmed server-side:

```sql
SELECT substring(id::text,1,12), kind, created_at, tags::text
FROM events WHERE kind = 1059 ORDER BY created_at DESC LIMIT 1;
-- 1059 | 2026-08-04 07:36:18+00 | [["p", ""]]
```

5. Recipient's desktop client, connected and a confirmed row in `relay_members`: **no message, no conversation, no notification.**

Posting the same content as a channel message (kind 9 into a `channel_type='dm'` channel) renders immediately, which is how we confirmed the client, relay and membership were all otherwise healthy.

## Why it matters

The failure is silent in both directions, which makes it expensive to diagnose — a sender integrating against the NIPs has every reason to believe delivery worked, and a recipient has nothing to notice. It also means the encryption a NIP-17 sender implements buys nothing on Buzz today: the practical fallback is a plaintext channel message, readable by the relay operator and every channel member.

## Possible resolutions (any would help)

1. Subscribe to and unwrap `1059` in the desktop client, surfacing it in the DM list.
2. If NIP-17 support is deliberately out of scope, **say so in the relay's NIP-11 document** — `supported_nips` currently advertises `17`, which is what led us to build against it. Advertising it at the relay while the first-party client cannot read it is the part that misleads.
3. Document the native DM kinds (`41001`/`41010`/`41012`/`30622`) as the supported path for third-party senders, so an integrator can implement the thing that actually works.

Happy to test a fix against our deployment.