Extract reusable Buzz client boundary

[MajorTal]

Hey good people - I wanted to start working on my own client, but the code is a bit of spaghetti and this is my attempt to untangle it. I’d like to extract the correctness-sensitive client logic currently trapped in crates/buzz-cli/src/client.rs into a new reusable crates/buzz-client library, with buzz-ws-client remaining the lower-level transport beneath it. The reason is that signing, NIP-OA authentication, community scoping, pagination, retries, and ambiguous delivery outcomes should have one authoritative implementation shared by every Buzz client (and NOT be reimplemented independently by the CLI, desktop, mobile, and my future client...).

The first change would just establish the intended final boundary immediately: an explicit community endpoint and configuration, an asynchronous signer abstraction, typed errors/results, and semantic delivery outcomes, but keep the scope deliberately small by migrating only channels list and messages send, preserving all existing CLI behavior while proving the same public API supports both the CLI and a minimal independent consumer.

What changed

• Added crates/buzz-client with explicit community, signer, authentication, retry, error, and delivery types.
• Moved the authenticated HTTP, pagination, upload, signing, retry, and stored-event delivery policy needed by the first two operations behind that public client API.
• Migrated buzz channels list and buzz messages send while keeping their command line behavior and output stable.
• Added an independent consumer workspace that lists channels and sends a message without importing CLI, Tauri, environment, or private workspace concerns.
• Left all other CLI operations on the existing client path.

Validation

• . ./bin/activate-hermit && just ci
• . ./bin/activate-hermit && just test-integration
• 22 focused buzz-client tests plus its documentation test
• 3 channel-list and 8 message-send CLI compatibility tests
• Independent consumer build and relay smoke test