Editing a message inside a thread duplicates it on every save and reorders the thread by edit recency

Reproduce on Tauri desktop at commit a9dd4d3 and capture the affected surface and authorship. Trace get_thread_replies, formatTimelineMessages/formatTimeline, and useEditMessageMutation while checking kind-40003 events and thread_metadata. Done means repeated edits update one row in place, show an edited indicator, and preserve thread order.

Describe the bug

Editing a message that is part of a thread appends a duplicate of the message on every save, with the duplicates ordered by most-recently-edited at the end of the thread. The signature matches a kind-40003 edit event being rendered as its own row: each save publishes a new event with a fresh created_at carrying the full new body — one duplicate per save, sorted to the end.

Steps to reproduce

1. Open a thread in a channel.
2. Message menu → Edit on a message in the thread; change the text; save.
3. Repeat the edit — one duplicate appears per save.

Observed on a downstream desktop build pinned to exactly a9dd4d3 plus a branding-only patch (no message/thread code changes), so the pipeline is vanilla Buzz at that commit. The exact surface (channel thread panel / home inbox / agent conversation / DM) and authorship (human vs agent-attributed) are not yet narrowed.

Expected behavior

The message updates in place with an "edited" indicator; thread ordering unchanged; no new rows.

Version and platform

• Buzz version: a9dd4d3 (Tauri desktop)
• OS: macOS (arm64)

Logs / additional context

At the pinned commit we verified clean, so the duplicate-producing path is still unidentified:

• NIP-10 ignores unmarked e tags, so edits never get a thread_metadata row and get_thread_replies never returns them.
• Every thread surface traced (channel thread panel, project panels, huddle transcript, home inbox, mobile) formats through formatTimelineMessages / formatTimeline, which never render kind 40003 as a row.
• Live-subscription aux merges dedupe by id; useEditMessageMutation patches caches in place.

Happy to attach a get_thread_replies payload capture for the affected thread once reproduced — kind-40003 events in that payload would point at relay-side thread membership rather than client rendering.