fix(desktop): downscale large avatars for agent-share PNG body

[wpfleger96]

Sharing an agent encodes a .agent.png snapshot with the avatar as the PNG image body. Non-PNG avatars were transcoded at full resolution and already-PNG avatars were carried through unchanged, so a large source avatar could produce a PNG that exceeds the 10 MiB MAX_SNAPSHOT_PNG_BYTES cap and fail the send. A 2764×4096 webp avatar encoded to ~26 MB — over 2.5× the ceiling — which is why sharing that agent hung for a few seconds (fetching and transcoding the image) and then failed.

The share dialog compounded the problem: on failure it discarded the pipeline's real error (Snapshot exceeds the 10 MiB size limit…) and toasted a generic Couldn't send … Try again., hiding the actual cause.

Changes

• Downscale the avatar for the snapshot PNG body. The body is only a card thumbnail, so raster avatars are now downscaled to a 512px longest edge (MAX_PNG_BODY_EDGE) before PNG re-encoding, mirroring the frontend SVG rasterizer's 512×512 cap in snapshotAvatarPng.ts. Already-PNG avatars over the dimension cap route through the same downscaling transcode path instead of a straight tEXt-chunk injection. The manifest's avatar_url/avatar_data_url source reference is untouched — only the PNG image body is downscaled.
• Surface the real error in the share dialog. PersonaShareDialog (used by SnapshotShareDialog/TeamShareDialog) and AgentCardViewerDialog now toast the send controller's actual error message, falling back to the generic string only when it is empty. A getCurrentError() accessor reads the error through a ref because the render-captured state.error is stale in the closure immediately after beginSend resolves.

A unit test pins the invariant: an oversize (2764×4096) avatar produces a snapshot that stays far under the cap with body dimensions clamped to 512px.

[wesbillman]

Mordecai, an automated reviewer, commenting via Wes’s GitHub account.

Reviewed source at ad20a1ea0fc453aa41582d263164ebd39349b58d. No blocking findings.

• Oversize and non-PNG avatars enter the decode/downscale/re-encode path; already-PNG bodies at or below 512px retain the existing inexpensive chunk-injection path.
• DynamicImage::resize(512, 512, Lanczos3) preserves aspect ratio while bounding both dimensions. The complete materialized PNG still passes through the existing 10 MiB validation, so large manifest payloads remain fail-closed.
• The manifest is constructed from the original avatar source independently of PNG-body encoding. The regression now verifies both the 512px body cap and preservation of avatar_url without inlining the oversized source.
• The synchronous error accessor is coherent: every send-state transition uses commitState, which updates the ref before React state, and both share-dialog call sites read it immediately after beginSend returns false. Team sharing delegates to the same SnapshotShareDialog.
• Updated E2E expectations assert the specific eligibility failures surfaced by this change.

Source-only review; I did not run tests or harnesses. Current GitHub checks are green.

[wesbillman]

Princess Donut, an automated reviewer, commenting via Wes's GitHub account.

Reviewed exact head ad20a1ea0fc453aa41582d263164ebd39349b58d with the avatar decode/resize boundary, manifest preservation, and stale React state paths as the primary lens.

CLEAR. I found no material correctness, security, or user-trust defect in the change.

Evidence:

• Oversize and non-PNG bodies converge on one decode → aspect-preserving 512px resize → PNG encode path; already-small PNGs retain the existing injection path (agent_snapshot.rs:336-349, :464-503).
• The manifest is built independently from the PNG body and still applies the existing 2 MiB inline/reference policy (agent_snapshot.rs:249-283); the regression test now verifies both the 512px body cap and preserved source URL.
• Every send-pipeline state transition now updates the ref before React state (useSnapshotSendController.ts:399-406, :424-449), so the post-await beginSend toast reads the failure that actually occurred rather than a stale render or generic fallback.
• The changed branch has green Desktop Core, desktop smoke/integration, macOS build, Windows Rust, and DCO checks in the current PR status.

One non-blocking observation: image decoding still materializes the source before resizing, so this improves output size rather than peak decode memory. That behavior predates this patch on the transcode path and the source bytes already pass existing media boundaries; it is not a regression here.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Consolidated Royal Court review at exact head ad20a1ea0fc453aa41582d263164ebd39349b58d.

No blocking findings. Oversized PNGs and non-PNG raster avatars converge on an aspect-preserving 512 px resize before PNG encoding, while small PNGs retain the existing direct path. The final 10 MiB snapshot guard remains in the shared materialization path. The manifest is built independently from the original avatar bytes/reference, and the regression now verifies both the body dimension cap and preservation of the source URL.

The ref-backed error accessor is coherent: all controller transitions update the ref synchronously before React state, so callers reading immediately after beginSend receive the current eligibility/encode/upload/send failure. Updated E2E expectations verify the user-visible eligibility messages.

I also checked malformed-image fallback, locked/plain shared encoding, output-size enforcement, and source/body separation. git diff --check is clean, and all applicable GitHub checks are green; path-filtered jobs are skipped as expected. I did not rerun CI-equivalent suites locally.