fix(cli): fail a thread read whose event is in another channel

[Chessing234]

Fixes #5800.

messages thread ORs two filters: replies scoped by #h and #e, and the root selected by ids alone. A --channel that does not match the event therefore returns the root and none of its replies, and exits 0 — which is byte-for-byte what a thread nobody answered looks like. The reporter's case is the dangerous one: an operator reads "no replies" and re-dispatches work that was already answered in the channel the event actually lives in.

Writes already refuse the same mismatch (ingest.rs: "parent event belongs to a different channel"); this makes the read agree, and names both UUIDs so the fix is a copy-paste away.

A root the relay did not return is left alone, so a genuinely missing event still prints an empty array rather than turning into an error, and a root with no h tag (nothing in this path publishes one, but the guard is cheap) passes through.

Verified locally: cargo test -p buzz-cli --lib (354 passed, 5 new), cargo clippy -p buzz-cli --all-targets clean, cargo fmt --all --check clean. Not run: a live relay — the shape of the two filters and the h-tag placement are read from messages.rs and the issue's own transcript.

[themiguelamador]

The new channel check still has two correctness gaps:

• It compares UUID text byte-for-byte, so an uppercase but valid --channel value falsely mismatches the lowercase UUID stored in the event.
• A returned root with no valid h tag passes through, even though the command cannot establish that the root belongs to the requested channel. (A genuinely missing root still needs to preserve the existing empty-result behavior.)

I fixed both in commit c9ae3c674: channel IDs are parsed and compared as UUIDs, event tag extraction follows the relay's first-parseable-h behavior, and a returned root without a valid channel now fails closed.

Verified with all 356 buzz-cli library tests, strict Clippy, rustfmt, and git diff --check.

[Chessing234]

Thanks — both fixed, in e8e17f8 and 45f7138. Complear/buzz 404s for me (gh api repos/Complear/buzz, and fetching c9ae3c674, both fail), so these are written from your description.

UUID comparison. event_channel_id now returns a parsed Uuid and the comparison is by value. It mirrors buzz_sdk::extract_channel_id — first parseable h tag rather than first h tag, so a junk tag ahead of the real one does not hide it — with a comment saying why the walk is duplicated (that helper takes nostr::Event; this path holds serde_json::Value).

One thing worth flagging: comparing by value would have been half a fix, so I went one step further than your description. The uppercase --channel is also wrong in the #h filter, not just in the comparison — h tags are lowercase hyphenated on the wire (NIP-PL h_grammar: "uuid-v4-lowercase", crates/buzz-relay/src/nip11.rs:215), so an uppercase argument matches no replies at the relay. Fixing only the comparison would have converted the false error into the silent "nobody answered" thread this PR exists to remove. So cmd_get_thread now canonicalizes once (parse_uuid → hyphenated()) and uses that for the filter and the check. Same for the {braced} and unhyphenated spellings Uuid::parse_str accepts — there is a test over all three.

Root with no valid h tag. Now fails closed with event <id> carries no readable channel (h) tag, …, covering both no h tag at all and an h tag that is not a UUID. A root the relay did not return is still passed through, so a genuinely missing event keeps printing an empty array rather than erroring — the test for that is unchanged.

Verified on the pushed head: cargo test -p buzz-cli --lib 358 passed (was 354; 4 net new), cargo clippy -p buzz-cli --all-targets -- -D warnings clean, cargo fmt --all -- --check clean, git diff --check clean. Still not run: a live relay.