fix(cli): accept generic uploads, surface message edits, list DMs

[JQuantAnalytics]

Summary

• Uploads: Replace the CLI media-only MIME allowlist with the desktop/relay deny-list so plain text and other generic files upload as application/octet-stream (HTML/SVG/executables still blocked).
• Message edits: messages get/thread overlay the latest kind 40003 edit onto the original (and hide raw edit rows by default); messages search includes 40003, resolves edit hits to overlaid originals, and migration 0025 adds 40003 to the fresh-install FTS allowlist so edited text is indexed.
• DMs: dms list no longer queries obsolete kind 41001; it lists membership + kind 39000 channels tagged t=dm (matches Desktop).

Context

Found during nest setup smoke on a fresh Buzz community: text upload failed client-side even though the relay already accepts generic files; edits succeeded but CLI reads looked stale; search missed edited bodies because the FTS allowlist omitted kind 40003; dms open worked but dms list stayed empty.

Test plan

• cargo test -p buzz-cli --lib upload_mime_
• cargo test -p buzz-cli --lib apply_message_edits
• cargo test -p buzz-db --lib embedded_migrator_contains_consolidated_initial_schema
• Live verify with locally built CLI: text upload → BlobDescriptor; dms list returns seeded DM; messages get shows overlaid edit body
• After merge + relay migrate 0025: buzz messages search --query "<edited text>" hits
• After Buzz.app CLI release: bundled buzz upload file --file note.txt / dms list / edit overlay

[sanjay3290]

The message-edit part of this PR overlays a kind 40003 edit onto its target without ever checking who signed the edit.

In apply_message_edits, the latest_edit map is keyed only on the edit's e tag and ranked only on created_at. There is no comparison between the edit's pubkey and the target event's pubkey. As written, any member of the channel can publish a 40003 tagging someone else's message and the CLI will render their text as the original author's content, under the original author's name.

It is also a suppression primitive, because the ranking runs before any validation: an attacker who publishes an edit with a created_at higher than the genuine author edit takes the map slot for that target. The author's real edit is discarded and never rendered.

The fix is a gate in the first loop, before the entry is inserted — not a check on the winner afterwards. Resolve target authors in a pass over the non-edit events first, then skip any edit whose pubkey does not match its target's author:

let mut target_pubkeys: HashMap<&str, &str> = HashMap::new();
for e in events {
    if is_edit(e) { continue; }
    if let (Some(id), Some(pk)) = (id_of(e), pubkey_of(e)) {
        target_pubkeys.insert(id, pk);
    }
}

for e in events {
    if !is_edit(e) { continue; }
    let Some(target_id) = first_e_tag_id(e) else { continue };
    // Author gate must run before ranking, or a forged edit wins the slot
    // and suppresses the genuine one.
    if target_pubkeys.get(target_id) != pubkey_of(e).as_ref() { continue; }
    // ... rank by (created_at, id)
}

Placing the check after winner selection looks equivalent and is not: it is only equivalent when exactly one edit exists for a target, which is the case most test fixtures cover. A three-event fixture — target(author), edit(author, t=2000), edit(other, t=3000) — distinguishes them. With the gate after ranking, that case renders the original content; with the gate before ranking, it renders the author's edit. Worth adding as a test case either way.

Same argument applies to cmd_search, which now resolves 40003 hits back to originals.