Fix CLI output normalization and wrong Nostr kinds (MCP parity)

[wpfleger96]

A full audit of the 54 CLI subcommands against their MCP equivalents revealed functional bugs throughout: channels list queried kind:39002 (member-lists) instead of kind:39000 (NIP-29 channel metadata), returning entirely wrong data; dms list queried kind:41010 instead of 41001; workflow runs queried the trigger kind instead of the run-lifecycle kinds. On top of that, every read command returned raw Nostr event JSON including sig fields agents never need, all write commands returned raw relay responses with no consistent shape, and create commands silently discarded the UUIDs they generated.

The MCP server already handles all of this correctly -- this brings the CLI to parity so agents can migrate without workarounds.

Kind number fixes

• channels list/get: 41 → 39000 (kind 41 is NIP-01 channel metadata, unused by Sprout; kind 39000 is NIP-29 group metadata, which is what the relay actually emits)
• channels members: uses #d tag filter (was #h)
• dms list: 41010 → 41001
• workflow runs: single kind → [46001, 46002, 46003] (doc-commented as returning empty -- relay stores runs in DB, not as events)

Output normalization

• All read commands return structured, sorted, sig-stripped JSON
• All ~25 write commands return {event_id, accepted, message}
• Create commands inject the generated entity ID (channel_id, dm_id, workflow_id) into the response
• canvas get returns the markdown content string directly, or null if not found
• reactions get aggregates by emoji with {emoji, count, pubkeys}, sorted deterministically; empty content defaults to "+" per NIP-25
• users get always returns an array (was returning a bare object for single results)
• workflows get returns normalized {workflow_id, content, created_at, pubkey}
• Thread filter restricted to message kinds [9, 40002, 40003, 40008, 45003] (was including reactions and system events)

Shared helpers in client.rs

• query_multi() sends multiple ORed filters in a single HTTP call; query() now delegates to it
• normalize_events(&[Value]) strips sig and sorts by created_at
• normalize_write_response() extracts {event_id, accepted, message} from relay responses
• extract_d_tag(), extract_p_tags() for consistent tag parsing (p-tag role is at index 3, not 2 -- index 2 is always an empty relay URL placeholder)
• extract_tag_value(event, key) generic tag value extractor, used by extract_channel_metadata
• print_create_response() reduces repeated blocks across channel/DM/workflow commands

Channel metadata fix

extract_channel_metadata was reading name and about from the event's content field (parsed as JSON). The relay emits kind:39000 events with content: "" and stores metadata in NIP-29 tags (["name", "..."], ["about", "..."]). All channel names were empty strings. Fixed to read from tags via extract_tag_value.

New flags

• channels list --limit <N>: limits results (default 500). Previously hardcoded.
• --format json|compact: global flag on all commands. compact reduces read output for agent scanning: channels → {channel_id, name}, messages → {id, content, created_at}, users → {pubkey, display_name}, feed → {id, content, created_at}. Write commands unaffected.

Bugs found during E2E testing

• messages search sent no kinds filter, triggering the relay's p-gate with 403. Now sends kinds: [9, 40002, 45001, 45003] matching the MCP server's search implementation.
• channels list --visibility open always returned [] because the filter checked for ["visibility", "open"] tags, but the relay emits ["public"]/["private"] per NIP-29. Rewritten to match the relay's actual tag convention.
• --kind flag on messages send was accepted but ignored (dead code). Now routes to the correct SDK builders: build_forum_post for kind 45001, build_forum_comment for kind 45003. This enables forum voting via CLI.

Safety fixes

• cmd_open_dm validates pubkeys before calling Tag::parse() (was panicking on malformed input)
• DM open parses relay-assigned channel_id from the response message field instead of fabricating a local UUID
• 403 errors hint when SPROUT_AUTH_TAG may be stale