feat(desktop): send authored link preview snapshots

[tellaho]

Overview

Category: improvement
User Impact: Link previews appear in the composer attachment tray and travel as privacy-safe sender-authored snapshots, so opening a conversation never contacts the linked site.
Problem: Recipient-side unfurling leaked link visits, composer cards looked like timeline content, and preview work could interfere with sending.
Solution: Resolve previews only in the sender's composer, upload finished preview media to the active community relay, attach only complete versioned snapshots at Send, and render only strictly validated snapshots on recipients.

Privacy and delivery model

• Sender-only fetching: origin metadata is resolved while composing. Compact attachment cards immediately show URL/domain identity—never “Preparing preview.”
• Zero recipient fallback: received and optimistic messages render authored snapshot tags only. Missing, stale, malformed, off-relay, unsupported, or suppressed snapshots stay ordinary visible links; recipients never regenerate them.
• Send never waits: submit atomically captures snapshots already ready at that moment. Pending or failed previews are gracefully omitted and are never added after send.
• Draft-wide suppression: one Hide previews X suppresses every preview in the current draft, including links pasted afterward. It emits only ["link-preview", "none"], preserves clickable URL text, and resets after send or clearing the draft.
• Durable but intentionally stale: snapshots preserve what the sender saw when sending; later origin changes do not silently rewrite message presentation.

Changes

• Render composer previews as stable 55px attachment cards at desktop and narrow widths.
• Show hostname/path/type while loading, then title/provider with local image or favicon fallback.
• Add one draft-wide Hide previews control rather than per-link removal.
• Carry ready snapshots or the exclusive suppression marker through native event construction.
• Validate the suppression marker in desktop and relay ingestion, rejecting duplicates or mixed snapshot tags.
• Keep recipient rendering authored-snapshot-only; plain links never trigger recipient origin fetching.
• Add deterministic E2E coverage for ready snapshots, immediate send while pending, global suppression, later pasted links, and reset after send.

Validation

At 11b60d88f:

• pnpm --dir desktop typecheck — passed.
• pnpm --dir desktop exec biome check src/features/messages/ui/MessageComposer.tsx src/features/messages/ui/useComposerLinkPreviews.tsx tests/e2e/messaging.spec.ts — passed.
• pnpm --dir desktop exec playwright test --project=smoke messaging.spec.ts — 42/42 passed.
• cargo test --manifest-path desktop/src-tauri/Cargo.toml link_preview_tags — 3/3 passed.
• cargo test -p buzz-relay link_preview_suppression — 3/3 passed.
• Push hooks — desktop check/test, Rust tests, and desktop Tauri checks passed.
• Real built-app screenshot capture — passed; desktop and narrow loading/ready states inspected below.

Screenshots

Desktop composer: loading	Desktop composer: ready

Narrow composer: loading	Narrow composer: ready

Recipient: Compact	Recipient: Rich

[Chessing234]

rich previews are nice. make sure they stay opt-in or gated for private/untrusted hosts so we dont fetch surprise content

[wesbillman]

Reviewing on Wes Billman's behalf. Requesting changes for a recipient privacy blocker at 60d348e526b96001acf6e57479b2fed3c6289245:

[P1 privacy] Merely viewing an unsolicited message automatically contacts sender-controlled hosts from the recipient's machine, with no off or consent control. Interactive unsuppressed messages extract preview URLs (desktop/src/shared/ui/markdown.tsx:1857-1863), the hook immediately loads each URL (desktop/src/shared/lib/useResolvedLinkPreviews.ts:223-277), and native code performs a direct GET with a Buzz Desktop user-agent (desktop/src-tauri/src/commands/link_preview.rs:191-215). The only preference is compact | rich, defaulting to compact—not off (desktop/src/shared/lib/linkPreviewStylePreference.ts:3-18). This exposes the recipient's IP and request timing to a message author without recipient action.

The SSRF hardening is strong, but it protects the machine rather than the user's network privacy. Please use a safe proxy, default-off/explicit enablement, consent before fetching, or another design that prevents unsolicited recipient-side requests. Please also add negative tests around the preview-specific URL gate (HTTP, credentials, non-443 ports, and private-IP hosts).