Desktop thread can render agent reply before triggering message under client clock skew

[andyylin]

Describe the bug

Buzz Desktop can render an agent response before the human message that triggered it when the sender's device clock is slightly ahead of the relay/agent clock.

Nostr's signed created_at should remain intact, but using it directly as the presentation-order key makes a successful agent response look missing. In the observed case, the agent reacted and replied normally, but its answer appeared above the question inside the thread.

Steps to reproduce

1. Use Buzz Desktop on a device whose clock is approximately 30–40 seconds ahead of the relay/agent host.
2. Open a channel thread containing an agent.
3. Send a reply that triggers the agent.
4. Wait for the agent to publish its response.
5. Inspect the thread ordering.

The agent's response appears before the triggering human message because the response has an earlier signed created_at, despite arriving at the relay later.

Expected behavior

The visible timeline should preserve causal/live message order under modest client clock skew, so an agent response does not appear before the message that triggered it.

This should not require rewriting the sender-signed Nostr event or its created_at. Possible approaches include a separate relay receipt sequence/timestamp for presentation ordering, a skew-corrected local observation key, or another stable ordering mechanism that retains authored time as metadata.

Version and platform

• Buzz version: 0.4.26
• OS: macOS 26.5.2, arm64
• Self-hosted relay source revision: c2a4ee711e481bb427d6cf8cd8b2c7329d1508c

Logs / additional context

Observed relay records (UTC):

Event	Relay received_at	Signed created_at
Human thread reply	2026-07-27 09:45:09.251015	2026-07-27 09:45:46
Agent response	2026-07-27 09:45:44.040725	2026-07-27 09:45:43

The relay received the human message first and the agent answer about 35 seconds later. Sorting by signed created_at reverses them, placing the agent answer three seconds before the human question.

Both events were kind 9 replies anchored to the same thread root. The agent also published processing reactions, confirming that delivery and execution succeeded; only the resulting timeline presentation was misleading.

Related but not duplicate:

• fix(desktop): anchor active-turn badge to skew-corrected agent start #1068 handles clock skew for active-turn elapsed timers.
• fix(acp): sort flushed batch events chronologically so replies thread under the right message #1872 fixes ACP replay-batch ordering and reply anchors.

Neither addresses visible message/thread ordering under sender clock skew.