feat(relay): make NIP-11 name and description configurable

[kajukabla]

Summary

The NIP-11 information document hardcoded name: "Buzz Relay" and description: "Buzz — private team communication relay", so self-hosters had no way to brand their relay. This adds two env vars, following the existing config patterns in crates/buzz-relay/src/config.rs:

• BUZZ_RELAY_NAME — NIP-11 name (default: Buzz Relay)
• BUZZ_RELAY_DESCRIPTION — NIP-11 description (default: Buzz — private team communication relay)

Values are trimmed; unset or blank values fall back to the current defaults, so existing deployments are unchanged.

Changes

• crates/buzz-relay/src/config.rs — new relay_name / relay_description config fields with DEFAULT_RELAY_NAME / DEFAULT_RELAY_DESCRIPTION consts; env parsing + tests (override, trim, blank fallback, defaults).
• crates/buzz-relay/src/nip11.rs — RelayInfo::build takes name/description as leading scalar params; nip11_document threads them from config. The _RELAY_INFO_BUILD_STATIC_INPUT_FENCE signature is updated accordingly — the new inputs are deployment-global config scalars resolved at startup (identical for every community), so the multi-tenant no-enumeration-oracle property is preserved; docs/multi-tenant-conformance.md row updated to match. New tests cover default branding and configured values served verbatim.
• .env.example (commented, dev) and deploy/compose/.env.example (self-host template) document the new vars. The compose relay service already passes the whole .env through via env_file, so no compose changes needed.

Client behavior (why this matters, and what it doesn't fix yet)

Neither client currently reads NIP-11 name/description — both fetch the NIP-11 document only for the icon field:

• Desktop: fetch_workspace_icon (desktop/src-tauri/src/commands/workspace.rs) deserializes only icon. The community display label comes from deriveCommunityName() (desktop/src/features/communities/communityStorage.ts), which string-parses the relay hostname (first subdomain label, with localhost/staging special cases), or from a user/deep-link-supplied name, and is user-renamable afterward.
• Mobile: community_icon_provider.dart reads only document['icon']. Labels come from Community.nameFromUrl() (hostname parsing) or the raw tenant host returned by /api/invites/claim — also hostname-derived, just server-side.

So this PR makes the relay advertise a proper operator-chosen identity (visible to any standard Nostr client and to future Buzz client work), but desktop/mobile will keep showing hostname-derived labels until they grow a NIP-11 name preference — a natural follow-up that this PR unblocks.

Testing

• cargo test -p buzz-relay --lib — nip11 + config suites pass, including new tests (default branding, configured values served verbatim, env override/trim/blank-fallback).
• just ci — every gate passes (fmt, clippy, Rust unit tests, desktop test/build, Tauri check/test, web build) except one pre-existing mobile widget test failure (channel_detail_page_test.dart:1042, "keeps follow mode off while a tall newest message stays visible"), which fails identically on a clean main checkout and is unrelated to this Rust-only change.

🤖 Generated with Claude Code