messages edit is accepted but get/history still show the original kind 9

## Repro (stock CLI v0.5.2)

1. `buzz messages send --channel --content 'edit-probe' --broadcast` → accepted, kind 9 event id `E`.
2. `buzz messages edit --event E --content 'edit-probe-UPDATED'` → accepted, kind 40003 event id `F` with tags `h` + `e(E)`.
3. `buzz messages get --channel ` still returns the original kind 9 content for `E`.
4. `buzz messages thread --channel --event E` shows both `F` (40003, new content) and `E` (kind 9, old content).

Live sample against a v0.5.2 relay (2026-08-20):

- send `5bd313b459b3886657bcf18cb931aa6baa242be78ccb11670effb2fa4b25f9bf` kind 9 `edit-probe 141148`
- edit accepted `f31fce0838880bd639ad68c13ea7d52275f66a4b3fb8325baaea97a929dd9cc2` kind 40003
- `messages get` still showed the original kind 9

## Expected

Read paths (`messages get` / history) apply the latest kind 40003 so callers see the edited content.

## Impact

Bridges and agents cannot verify edit round-trips. Slack-style edit mirroring into Buzz is invisible on get/history.

Start by tracing the `messages get` and history read paths, using the reported `messages edit` and `messages thread` behavior as the reproduction. Follow how kind 40003 events reference the original event E, then verify that get/history return the edited content while thread behavior remains correct.

Written by the indexing model from the issue text.