fix(link-previews): proxy sent preview media

[tellaho]

Overview

Category: fix
User Impact: Sent link previews now reliably display their thumbnail and favicon when the media is hosted on the relay.

Problem: Sent preview cards loaded relay-hosted snapshot media directly, so authenticated relay requests could fail even though the snapshot itself was valid. Solution: Rewrite snapshot media at the shared card render boundary through Buzz's authenticated local media proxy, preserving the original display domain and rerendering when the proxy becomes ready.

Changes

File changes

desktop/src/shared/ui/link-preview-attachment.tsx
Routes sent preview thumbnails and favicons through authenticated relay media handling above the Compact/Rich fork while preserving original metadata.

desktop/src/testing/e2eBridge.ts
Adds an opt-in proxy-readiness seam that deterministically re-arms the production media lookup when released.

desktop/tests/e2e/messaging.spec.ts
Covers the real send, snapshot, recipient, and card-render path for Compact and Rich previews, including fallback URLs, proxied URLs, and decoded image content.

desktop/tests/helpers/bridge.ts
Exposes the opt-in media-proxy startup state to E2E tests.

Reproduction Steps

1. Send a link whose preview snapshot includes a relay-hosted thumbnail and favicon.
2. Inspect the sent message card in Compact mode and confirm both images render after the local media proxy becomes ready.
3. Switch link previews to Rich mode and confirm the thumbnail and favicon continue to render.
4. Run the focused Playwright regression:
   pnpm exec playwright test tests/e2e/messaging.spec.ts --project=smoke --grep "sent link preview media uses the authenticated proxy"

Before / After

Before	After
Relay-hosted preview media fails to load.	The sent preview thumbnail and favicon render through the authenticated media proxy.

[wesbillman]

Reviewed on Wes’s behalf at exact head 48eccf547e2358f9f97b4b4e7453bb2af0b86dbf. No actionable findings from my pass. The render-boundary rewrite is correctly shared by Compact and Rich cards, preserves the original imageDomain, leaves data/external URLs unchanged, and subscribes to proxy-port publication so initial buzz-media:// fallbacks are replaced without requiring unrelated state changes. Snapshot parsing already restricts authored media to exact active-relay /media/<sha>.<image-ext> URLs tied to message content, so this does not widen the proxy trust boundary. I also traced cache reset/community-switch behavior: the existing generation guard prevents stale origin/port publication, and useMediaProxyPort rerenders on both cleared and newly resolved ports. The new E2E exercises send → uploaded snapshot → recipient parse → Compact render, delayed proxy readiness, decoded image content, and Rich rerender. git diff --check origin/main...48eccf547e2358f9f97b4b4e7453bb2af0b86dbf passes; current GitHub CI is fully green and the head is mergeable. Per policy, this is findings-only, not an approval.

[wesbillman]

Adversarial review at exact head 48eccf547e2358f9f97b4b4e7453bb2af0b86dbf: no actionable findings.

I traced the complete path rather than only the new E2E:

• Recipient-side external cards come exclusively from validated sender snapshot tags (parseLinkPreviewSnapshots), whose media pairs are constrained to the active relay origin and matching 64-hex path/hash. This means the new render-boundary rewrite receives the relay-owned URLs it is intended to proxy, not arbitrary external image URLs.
• LinkPreviewAttachment rewrites both favicon and image before the Compact/Rich fork, so every sent-card shape receives the same treatment while the original imageDomain remains intact for display/alt metadata.
• The useMediaProxyPort subscription closes the cold-start race: initial rendering may use the buzz-media:// fallback, and the component rerenders when fetchProxyPort publishes a nonzero port. Existing cache-generation guards prevent a lookup from a previous community from repopulating the cache after reset.
• rewriteRelayUrl still passes external Blossom media through once the relay origin is known, and snapshot parsing independently rejects non-relay media for this path.
• The E2E exercises the actual compose → upload → signed snapshot → recipient parse → Compact render flow, then releases proxy readiness and verifies both URL transition and decoded image content before switching to Rich and checking both media elements again.

I also checked failure-state behavior: the child components key image failures by the current rewritten URL, so an initial fallback/proxy failure does not permanently poison a later URL transition.

git diff --check origin/main...HEAD passes on a clean detached worktree. GitHub reports the exact head mergeable with all applicable checks terminal and green. I did not duplicate CI-equivalent suites locally.