Add KLIPY GIF search to desktop composers

[klopez4212]

Summary

• supersedes Add KLIPY GIF search to message composers #1913 with a KLIPY-hosted URL implementation
• adds KLIPY GIF search and trending results to desktop message and forum composers
• keeps selected GIFs hosted by KLIPY; Buzz stores only the external URL and media metadata
• aligns the Emoji/GIF picker with Buzz's standard segmented control, theme surfaces, motion, and reduced-motion behavior

Validation

• desktop formatting, lint, and TypeScript checks
• 4,608 desktop tests
• production and E2E builds
• native staging review in light mode

[wpfleger96]

🤖 Thanks for putting this together — the relay proxy is genuinely well built. The key stays server-side with a redacted Debug impl, NIP-98 verification requires the payload hash, and there's a replay guard, membership + per-pubkey quota enforcement, an upstream response-size cap, and allowlisting so KLIPY error bodies never cross the relay boundary. That whole boundary held up under both source review and a live run against the real KLIPY API.

I'm requesting changes on two blocking issues, both verified end-to-end, plus one design question I'd like resolved before merge:

1. Selecting a GIF produces a message the relay refuses to ingest — the core feature doesn't work end-to-end. A live run against this branch got 400 {"error":"invalid: imeta url must be a local /media/ path"} on both stream (kind 9) and forum (kind 45001) sends, with zero posts persisted. Details inline at desktop/src/features/gifs/api.ts.

2. The PR breaks its own smoke test: composer-tooltip-dismiss.spec.ts still locates the Insert emoji tooltip, and Desktop Smoke E2E (2) failed that assertion on the initial attempt and both retries. Details inline at ComposerEmojiPicker.tsx.

3. KLIPY's own reference integrations couple sends to their share/report endpoint, and this PR documents skipping that as a non-goal — I don't think that call is as free as the docs suggest. Inline comment on crates/buzz-relay/src/api/gifs.rs with references.

There are also a few smaller things inline (upstream client reuse, handler-level test coverage, per-relay customer_id keying, and some nits).

[wpfleger96]

🤖 All feedback from the combined review is addressed at 9db36e2 — verified each finding at source, and both blockers are confirmed fixed: external GIFs now send as content-only markdown (no imeta tag, so the relay validator is never engaged) and the tooltip smoke spec is green. The new /gifs/share endpoint sits behind the same NIP-98/membership/replay boundary as search, and live E2E against the real KLIPY provider confirmed sends persist and render on both kind 9 and forum posts, plus fully graceful degradation (no GIF tab, no errors, zero /gifs/* requests) when the relay has no KLIPY key. CI is fully green at head.