feat: NIP-29 channel subgroups — hierarchical channel organization

**Problem**
Buzz currently has no way to organize channels into hierarchical groups (like Discord categories). All channels are flat, which becomes unmanageable at scale.

**Our use case:**
We self-host a Buzz relay with 106+ channels across multiple 'categories' (AI agents, commercial funding, work sales, real estate, consulting). Without hierarchy, users must scroll through a flat list of 106 channels with no visual grouping.

**What NIP-29 Specifies**
The [NIP-29 spec](https://github.com/nostr-protocol/nips/blob/master/29.md) defines subgroups via the parent tag on kind:39002 (group metadata) events. A relay that supports subgroups should advertise "subgroups": true in its /info response.

**Current Behavior**
/info returns "nip29": {"subgroups": false}
Sending a kind:39002 event with a parent tag returns "actor not authorized"
No env var or config flag enables subgroups
All 106 channels appear flat in the desktop app

**Proposed Solution**
Implement NIP-29 subgroup support so channels can have parent/child relationships:

Relay: Accept and persist parent tags on kind:39002 events
/info: Advertise "subgroups": true when implemented
CLI: buzz channels create --parent to nest channels
Desktop: Render channels in a tree view with collapsible groups

**Why This Matters**
Discord has ~200M+ users organized around category/channel hierarchy
Slack has channels + sections (similar concept)
Without subgroups, Buzz channels scale poorly beyond ~20-30 channels
Self-hosted communities (like ours) need organization for multi-team/multi-project setups

We are using prefix naming (HERMES • channel-name, MCF • channel-name) as a visual grouping hack, but this is fragile and doesn't provide real hierarchy.

**Alternatives Considered**
User groups (https://github.com/block/buzz/issues/2728) — solves member grouping, not channel hierarchy
Channel templates — organize at creation time, not at runtime
External relay with subgroup support — none production-ready as of mid-2026

**Related**
https://github.com/block/buzz/issues/2851

Start by reading the linked NIP-29 specification, then trace the relay handling for kind:39002 events and the /info response. Review the proposed CLI command `buzz channels create --parent` and desktop channel view entry points; done means parent tags are accepted and persisted, capability is advertised, and channels render hierarchically.

Written by the indexing model from the issue text.