messages send and dms open return 405 Method Not Allowed against a hosted community relay, while channels/identity operations succeed

**Relay / community:** `wss://astgl.communities.buzz.xyz`

**App/CLI version:** 0.5.19 (`buzz` binary bundled in Buzz.app; no `--version`/`-V` flag on the CLI itself, version taken from the app bundle's `CFBundleShortVersionString`)

## What's failing

Every variant of sending a message returns a `405`, while channel-membership and identity operations against the *same relay* succeed:

```
$ buzz messages send --channel --content "hello" --mention
{"error":"error","message":"could not load channel membership for mention preflight","retryable":false}

$ buzz messages send --channel --content "hello"
{"error":"relay_error","message":"relay error 405: Method Not Allowed","retryable":false}

$ buzz messages send --channel --content "hello" --broadcast
{"error":"relay_error","message":"relay error 405: Method Not Allowed","retryable":false}

$ buzz dms open --pubkey <64-char-hex>
{"error":"relay_error","message":"relay error 405: Method Not Allowed","retryable":false}
```

## What's working, on the same relay/community

```
$ buzz identity publish --join
# succeeds — agent's kind:0 posts, and Buzz Desktop shows " joined the channel"
# with the member count incrementing correctly
```

## Why this looks like a backend gap rather than a client/config issue

- The identical CLI, pointed at the same relay, succeeds for `channels join` / `identity publish` (kind:0 + membership) but fails for every message-sending path (plain, mentioned, and explicit `--broadcast`) with the same `405`.
- The mention-preflight error is a distinct failure mode (couldn't even load channel membership for the preflight check) from the plain `405` on send, suggesting the messaging-related endpoints may simply not be deployed/routed on this community's backend.
- An @-mention sent through Buzz Desktop's own UI for the same unresolved-in-directory agent silently produced no visible error and no notification, consistent with Desktop's send path hitting the same gap without surfacing it to the user.

## Reproduction context

- Agent was minted via `buzz identity mint `, published via `identity publish --join ` (succeeded), and confirmed as a channel member in Buzz Desktop (member count incremented, "X joined the channel" system message shown).
- The agent's own external client (a separate Nostr client connecting via the same relay) confirmed a clean WebSocket connection, channel subscription, and "presence: online" — so the relay is reachable and functioning for at least the connection/subscription/presence layer.
- All `messages send` / `dms open` attempts above were run directly against the `buzz` CLI binary with a valid owner private key (`BUZZ_PRIVATE_KEY`) already verified to work for the identity/channel operations that succeeded.

Happy to provide more detail (full CLI version, additional flags tried, etc.) if useful.

Start by reproducing `messages send` and `dms open` against `wss://astgl.communities.buzz.xyz`, then compare their relay requests with the successful `channels join` and `identity publish` paths. Trace the backend routes or handlers for messaging and direct-message operations; done means message sends and DM opens no longer return 405 while the existing identity and membership operations still succeed.

Written by the indexing model from the issue text.