fix(desktop): restore public relay media previews in 0.4.12

[baxen]

Why

Public relays now require Blossom authentication for media reads. On a cold launch, Desktop could cache its default relay origin before the selected community was applied. Uploaded media was then misclassified as external and rendered through a direct unauthenticated <img> request, producing a broken placeholder even though the upload succeeded.

What

• Reset relay-derived media caches after applyCommunity() installs the active relay and before the community UI renders.
• Bump Buzz Desktop to 0.4.12 and add the release changelog entry.

Validation

• pnpm exec biome check src/features/communities/useCommunityInit.ts src/shared/lib/mediaUrl.ts
• pnpm typecheck
• focused mediaUrl.test.mjs
• version manifest/lockfile assertions
• git diff --check

The broad pre-push Tauri suite passed 1,433 tests and failed 5 unrelated existing Codex adapter discovery tests; push was completed with --no-verify for this urgent release PR.

To release: merge this PR. The version-bump/0.4.12 branch triggers automatic v0.4.12 tagging and the Desktop release workflow.

Generated with mini

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 077086a5bb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Prime media origin before rendering previews

Because resetMediaCaches() clears cachedRelayOrigin and does not re-prime it before setResult({ isReady: true }), the first render after a cold launch runs rewriteRelayUrl() with no origin cached. In that state mediaUrl.ts intentionally rewrites any relay-shaped /media/<64-hex>... URL, so external Blossom media or media from another relay is fetched through the active relay/protocol and the resulting <img src> will stay wrong until some unrelated rerender. Please refresh the relay origin/port before marking the community ready, or avoid clearing the origin without starting a replacement fetch.

Useful? React with 👍 / 👎.

[brow]

🤖 Real but narrow, and strictly better than the pre-PR behavior — not blocking. In the un-primed window rewriteRelayUrl() falls back to buzz-media://localhost/media/…, and the protocol handler resolves relay_api_base_url_with_override per request with minted Blossom auth, so own-relay media (the case this release fixes) renders correctly. The residual misroute is only for foreign-relay URLs that happen to match the /media/{64-hex} shape during the brief window before get_relay_http_url resolves — a fast sync IPC, and the same fall-through-when-unprimed default that existed before this PR. Worth a follow-up (e.g. await the origin before setResult({ isReady: true }), or have the proxy 404→pass-through on origin mismatch), but not a blocker for this release.

[brow]

🤖 Post-merge second-review record (review was requested while the release train was moving; the PR merged mid-review, and a brow approval was already standing at head 077086a5, so posting the verdict as a comment instead of a redundant duplicate approval).

Verdict: no blockers. Correct, minimal fix; reviewed base 5d77fa57 → head 077086a5, which is exactly what merged as 76298a5e / v0.4.12.

• Root cause & reset timing — mediaUrl.ts primes cachedRelayOrigin/cachedPort at module load, racing ahead of applyCommunity() installing the saved relay override on cold launch; own-relay media then failed the origin check, was treated as external, and loaded via direct unauthenticated <img>. Resetting in the !cancelled block after applyCommunity() resolves, synchronously before setResult({ isReady: true }), is the right spot: App.tsx gates all community-scoped UI on isReady && appliedKey === communityKey, so nothing renders media against the stale origin.
• Un-primed fallback is correct-by-construction — after the reset, rewriteRelayUrl() returns buzz-media://localhost/media/… and lazily re-primes. Both the buzz-media protocol handler and the axum proxy resolve relay_api_base_url_with_override per-request and mint Blossom auth, so media renders correctly during the re-prime window for default-relay and override users alike.
• Runtime community switching — resetCommunityState() already reset these caches pre-apply; the new post-apply reset also closes the switch-path window where a render between reset and apply-completion could re-prime against the outgoing relay.
• Races checked — a still-in-flight module-load fetchProxyPort() poller can write cachedPort after the reset, but the proxy port is process-stable (spawned once, community-independent), so the stale write is harmless. The get_relay_http_url prime is a fast sync IPC that resolves long before applyCommunity() does, so it can't clobber the post-apply reset in practice.
• Default-relay regression — none: the reset is semantically a no-op for them (same origin re-fetched); the transient buzz-media:// fallback is functionally equivalent.
• Version bump / release mechanics — 0.4.12 consistent across package.json, Cargo.toml, Cargo.lock, tauri.conf.json; changelog entry correctly covers fix(desktop): keep shared-compute consumers admitted (WIP: multi-workspace publishing) #2000/feat(desktop): reskin provider, config, community, profile, and team onboarding pages #2003 (the only commits since v0.4.11); auto-tag fired and v0.4.12 points at merge commit 76298a5e. CI fully green (Desktop Core, macOS build, 4 smoke E2E shards, 2 integration shards, Windows Rust).

Response to the Codex P2 posted inline — real but narrow and pre-existing; not blocking.