fix(cli): default root send to kind 45001 in forum channels

[iroiro147]

Resolves #5075.

Problem

buzz-cli messages send <channel-uuid> "..." publishes every root message as kind: 9 regardless of the channel's actual kind. When the target channel is a forum, the message lands on the invisible stream surface — it never appears in Buzz Desktop's forum topic list, even though submit_event returns success. Operators must currently pass --kind 45001 by hand every time, and there is no in-CLI signal that the default would misroute the message.

Fix

Make the default kind channel-type-aware. On a root send (no --reply-to, no explicit --kind):

• Query the relay for the target channel's kind: 39000 metadata event and extract its ["t", ...] tag (forum | stream).
• If forum: emit kind: 45001 via build_forum_post so the new topic shows up in the canonical forum view.
• If stream or unresolvable (no metadata, no t tag): fall back to kind: 9 via build_message, preserving existing behaviour.

Two hard rules:

1. An explicit --kind always wins. --kind 9 into a forum channel is still allowed and still misroutes — that is the operator's call, not ours. The bug in buzz messages send defaults to an invisible stream event for forum roots #5075 is the default, not the override.
2. Reply flows are untouched. --reply-to follows the existing thread-resolution path unchanged; issue [Bug] Agent forum replies publish as kind 9 and disappear from the forum thread #3828 covers kind-45003 inference from the parent event and is deliberately a separate fix.

Implementation

• fetch_channel_type: POST /query with {"kinds":[39000],"#d":[uuid],"limit":1}; parses the tags array for ["t", <value>]; returns Ok(Option<String>). Errors only on transport/wire-shape failures so malformed 39000 does not silently fall through to kind 9.
• resolve_send_root_kind: pure function (explicit: Option<u16>, channel_type: Option<&str>) -> u16. Encoding the decision as a pure fn (rather than inline in cmd_send_message) lets the regression tests run without network mocking.
• The I/O call is only made when both p.kind and p.reply_to are absent — no extra round-trip on paths that don't need it.

Tests

cargo test --package buzz-cli --lib commands::messages::tests — 29 passed, 4 new:

• resolve_send_root_kind_forum_default_becomes_45001
• resolve_send_root_kind_stream_default_stays_9
• resolve_send_root_kind_unknown_type_falls_back_to_9
• resolve_send_root_kind_explicit_overrides_forum_default

Notes

• This PR is independent of fix(cli): emit kind 45003 for replies into forum threads #3885 (replies / kind-45003 default). They touch nearby code but different concerns — this one only fires when reply_to.is_none().
• The fetch_channel_type shape intentionally mirrors resolve_channel_id in the same file so the relay query pattern stays idiomatic.