fix(desktop): preserve authoritative agent avatars

[tellaho]

Category: fix
User Impact: Agent cards and catalog listings now show the avatar belonging to the identity they represent.

Problem: Running agent cards could show a stale definition avatar instead of the concrete agent profile, while adding another publisher's catalog entry could let local edits repaint that publisher's listing. This made agent identity look inconsistent across My Agents and the Agent Catalog.

Solution: Treat the concrete agent pubkey profile as authoritative for running-card avatars, with the linked definition as fallback. Keep relay publications authoritative for foreign catalog presentation while using local copies only for linkage and selection state.

before	after
agent-set avatar not showing	agent-set avatar is showing

Changes

File changes

desktop/src/features/agents/lib/agentCardAvatar.ts
Adds the explicit avatar precedence rule for running agent cards and blocks avatar-dependent actions until the authoritative profile query settles.

desktop/src/features/agents/lib/agentCardAvatar.test.mjs
Covers profile precedence, definition fallback, blank avatar handling, and the profile-loading transition for linked-agent actions.

desktop/src/features/agents/lib/personaCatalogRelay.ts
Keeps publisher-provided catalog identity and behavior fields authoritative after a local copy is added.

desktop/src/features/agents/lib/personaCatalogRelay.test.mjs
Verifies local copies contribute linkage and selection without overriding publisher presentation.

desktop/src/features/agents/ui/UnifiedAgentsSection.tsx
Uses the concrete agent profile avatar before the linked definition avatar on running-agent cards.

Reproduction Steps

Running agent card uses the agent profile avatar

Use two visibly different, publicly reachable image URLs: A for the saved definition and B for the running agent profile.

1. In Settings → Experiments, enable Agent-managed profiles. This prevents Desktop from restoring the definition avatar over an agent's own relay-profile changes.
2. In Agents, create an agent with image A as its avatar and start it.
3. In a channel containing that agent, ask it to update its own Buzz profile avatar to image B. The exact CLI operation under the agent identity is buzz users set-profile --avatar <image-B-url>.
4. After the agent confirms the update, reopen Agents → My Agents (or reload the page so its kind:0 profile is fetched again).
5. Verify the running agent card shows image B, not definition image A. Open ⋯ → Share and verify the share flow also uses image B.

Before this fix, the My Agents card and share flow preferred image A whenever the linked definition had an avatar.

Catalog listing remains publisher-authoritative

This scenario requires a second Buzz identity so the entry is foreign to the account under test.

1. As the publisher identity, create an agent definition with a distinctive name, avatar, and instructions, then use Share → Share to catalog.
2. As the test identity, open Agents → Discover agents, find that publication, and add it.
3. In My Agents, open the added copy's ⋯ → Edit, change its name, avatar, and instructions, and save.
4. Return to Discover agents and find the same publisher entry.
5. Verify it remains selected/added but still shows the publisher's original name, avatar, and instructions—not the test identity's local edits.

Validation

• pnpm test — 4,376 passed
• pnpm typecheck — passed
• pnpm check — passed with existing non-error notices

[wesbillman]

Reviewed exact head 7647d7d813a98223373c977f89e9036af4c90ddd on Wes Billman's behalf.

No blocking findings. I traced the running-card avatar path through the concrete pubkey profile query, fallback resolution, and avatar-dependent Share/Export action gating; the profile remains authoritative once resolved while an absent/blank profile picture falls back to the linked definition. I also traced foreign catalog projection and activation: relay publication fields now remain authoritative for presentation, while the local copy contributes only its linkage id and active/selected state, and Add correctly reuses/reactivates that copy rather than minting another.

The focused unit coverage pins precedence, blank handling, loading behavior, foreign-copy provenance, and publisher-authoritative presentation. A clean merge tree against current origin/main (1399ec1d13c4560f50fd947e504deeea70929751) is conflict-free and preserves the newer runtime-control work. All CI checks reported for the reviewed head are green.

This is a technical review comment, not an approval; approval remains Wes's decision.

[wesbillman]

Reviewed commit 7647d7d813a98223373c977f89e9036af4c90ddd adversarially. No blocking findings.

I traced both authority boundaries end to end:

• Linked cards resolve the selected concrete agent's kind:0 avatar before the definition fallback, and avatar-dependent Share is held until the profile query settles, preventing a fallback avatar from being snapshotted during initial loading.
• Catalog projections retain only the local copy's linkage id and active state; publisher-controlled display name, avatar, prompt, runtime/model/provider, name pool, and behavior remain sourced from the relay publication. The add flow still resolves the local copy by publisher/persona coordinates and avoids duplicate copies.

I also checked the conflict-free merge tree against current origin/main (1399ec1d13c4560f50fd947e504deeea70929751). Existing focused tests cover precedence, blank/missing fallback, loading-state gating, and foreign catalog authority; CI is green at the reviewed head.