fix(cli): send forum roots and replies as forum kinds

[Chessing234]

Fixes #5075.

messages send published kind:9 whenever --kind was omitted. Desktop's forum surface lists kind:45001 topics and their kind:45003 comments, so a default send into a forum channel is accepted by the relay, returns an event id, and never appears where people read that channel. It stays reachable by notification or deep link, which is what makes it look like a delivery problem rather than a kind problem.

The send now resolves the channel's type from its kind:39000 discovery event (t tag, written by emit_group_discovery_events) and picks the kind that channel's canonical surface shows: 45001 for a forum root, 45003 for a forum reply, 9 everywhere else. An explicit --kind is honoured unchanged, and --broadcast stays on kind:9 — broadcast is a stream concept, and a flag should not silently redirect the event kind. A channel with no discovery event keeps the stream default rather than failing the send.

Acceptance criteria from the issue: root send to a forum publishes 45001 ✅, stream sends still publish 9 ✅, explicit override unchanged ✅, regression tests for both defaults ✅, --kind help now names the kinds ✅. The one I cannot tick myself is "appears as a topic in Desktop's forum surface" — I have no forum channel to send into; the claim rests on Desktop listing 45001, which is the issue's own evidence.

Verified locally: cargo test -p buzz-cli --lib (355 passed, 6 new), clippy and fmt clean. The extra kind:39000 read costs one query per send that omits --kind; sends already query channel members for mention resolution on the same path.

[themiguelamador]

The forum default still has an invisible-success path: --broadcast forces an implicit forum send back to kind 9. That event is accepted but omitted from Desktop's forum surface—the same user-visible failure this PR fixes. The PR describes broadcast as stream-only, so a forum invocation should fail clearly rather than silently publish hidden content. Explicit forum kinds combined with --broadcast also ignored the flag.

I consolidated selection into a tested resolve_message_kind contract. Ordinary forum roots/replies remain 45001/45003; forum broadcast is rejected; explicit forum kinds reject the ignored broadcast flag; and explicit --kind 9 --broadcast remains the expert opt-out. Selection now runs before attachment upload, preventing invalid broadcast combinations from leaving orphaned media. CLI help identifies broadcast as stream-only.

Fix: Complear/buzz@c56c71995 (review/pr-5925-fix)

Verified: full buzz-cli unit suite (357 passed); cargo clippy -p buzz-cli --all-targets -- -D warnings; rustfmt; git diff --check.

[Chessing234]

Thanks — all of it addressed, in af89a28, b8b7027 and d281d5f. Complear/buzz 404s for me (gh api repos/Complear/buzz and fetching c56c71995 both fail), so this is written from your description.

default_message_kind is gone; selection is now one contract, resolve_message_kind(explicit, channel_type, is_reply, broadcast) -> Result<u16, CliError>, with the whole policy in its doc comment:

• implicit forum + --broadcast → rejected. You are right that the fallback to kind 9 was the same invisible success the PR is fixing, reachable by adding a flag. The error names the opt-out.
• explicit --kind 45001/45003 + --broadcast → rejected. Confirmed the flag was being dropped: build_forum_post and build_forum_comment take no broadcast argument, so there was nothing to honour.
• --kind 9 --broadcast → still allowed, in a forum channel too, since the caller named the kind.
• implicit forum root/reply → 45001/45003 unchanged; everything else → 9.
• the unsupported---kind error moved in here too, so every kind decision has one home.

Before the upload. Selection now runs before the attachment loop, so a rejected combination cannot leave media stored with no event referencing it. That also covers --kind 7 --file …, which previously uploaded and then rejected the kind. The reply flag reads p.reply_to.is_some() rather than thread_ref.is_some() — equivalent (thread_ref is Some exactly when reply_to is), and it means the kind is settled without waiting on the parent-event round-trip.

Help. --broadcast now reads "Also publish to the Nostr network. Stream-only (kind 9): rejected in a forum channel and with --kind 45001/45003". Verified in the generated buzz messages send --help.

Verified on the pushed head: cargo test -p buzz-cli --lib 360 passed (was 355; 7 new cases covering both rejections, the --kind 9 --broadcast opt-out, broadcast on a stream channel, and the unsupported kind), cargo clippy -p buzz-cli --all-targets -- -D warnings clean, cargo fmt --all -- --check clean, git diff --check clean. Still unverified on my side: the Desktop forum surface itself, since I have no forum channel to send into.