Chatbox renders agent replies on channel re-entry, then drops them ~1s later (intermittent render bug)

# Chatbox renders agent replies on channel re-entry, then drops them ~1s later (intermittent render bug)

**Environment:** Buzz Desktop (macOS), relay `wss://parklife22.communities.buzz.xyz`. Observed 2026-08-12 by operator `@Asubekti` with agents Honey, Bumble, Fizz.

## What happens
In a channel where an agent IS active, the agent's replies frequently fail to appear in the Chatbox — even though the events exist on the relay. The failure is **intermittent**, and has a clean, reproducible signature:

> Operator left the channel and re-entered. The previously-missing agent reply **flashed into the Chatbox**, then **disappeared again ~1 second later**.

This proves the event is present in the client's loaded data (it renders on mount) — so the defect is in the **post-load render / reconciliation path**, not in relay delivery, publishing, or session attach.

## Why it is NOT a "session not attached / 0 events" problem
An earlier draft claimed `Fizz never published to the channel` (a managed-agent shell reported `0 Fizz events`). That count is a **stale-relay artifact**: managed-agent shells resolve a stale relay host (`xyz.block.buzz.app`, times out) instead of the workspace relay, so their queries return empty. The operator's own Buzz Desktop client — the authority for this workspace — proves the Fizz events exist (they render on re-entry). Do not cite that "0 events" count as evidence.

## Evidence (Group DM (4), channel `8be6be0f-20f3-4296-9cc5-281806b70c72`)
"Renders?" = operator observation; human events in the same channel always render and stay.
- Asubekti (human) 08:31:18 ✅ stays
- Honey (agent) 08:32:19 ❌ (and flashes on re-entry, drops ~1s)
- Bumble (agent) 08:33:08 ❌ (and flashes on re-entry, drops ~1s)
- Honey (agent) 08:38:21 ❌
- Bumble (agent) 08:41:29 ✅ stays
- Honey (agent) 08:43:10 ✅ stays
- Bumble (agent) 08:43:31 ✅ stays
- Honey (agent) 08:44:15 ✅ stays
- Fizz (agent) multiple replies this session — render on re-entry, drop ~1s

Same agents, same channel: some events stay, some flash-then-drop, some never show. A static author-kind filter would fail them all — this is an **intermittent client-side race / reconciliation (dedup / re-applied seen-filter on the live subscription) bug**.

## Corroborating
- Group DM (3) `3aefcfe8-…`: Fizz replies (`5dc6436f1ddc5448`, `e953322a41201430`) on relay ✅; operator reported agent replies showed in "activity" but not chatbox.
- DM 1-on-1 `62387774-…`: Bumble `e9b9e7596433ffb5` on relay ✅; preceded by "belum muncul di chatbox".

## Repro (clean)
1. In a channel where an agent is active, have the agent reply.
2. Leave and re-enter the channel.
3. The agent's previously-missing reply flashes in, then disappears ~1s later.

## Suggested fix
Inspect the agent-event render/reconciliation path for a step that runs **~1s after mount** (re-applied seen/read filter on the live subscription, a dedup/reconcile pass, or a re-render that drops agent-authored events). Human events always stay, so the divergence is specific to agent-authored event display. Add a regression test: mount a channel with pre-existing agent events and assert they remain visible after the post-load reconcile.

---
*Correction history: an earlier version of this issue mis-attributed the Fizz/DM(4) episode to a missing session (Mode 2). The operator's re-entry test disproves that — the events render on load, so it is a render bug (Mode 1). See comments for the original correction thread.*

Start by reproducing the channel re-entry behavior in the Buzz Desktop Chatbox, then trace the post-load live-subscription reconciliation and agent-event display path. Add the suggested regression test with pre-existing agent events and verify they remain visible after the roughly one-second reconcile step.

Written by the indexing model from the issue text.