buzz-cli `messages send` hard-fails the whole message (exit 1) when content contains a bare @-token that doesn't resolve to a channel member

[RelativelyIrrelevant]

Bug

buzz messages send --channel <cid> --content - rejects the ENTIRE message whenever the content contains a bare (unquoted) @-token that does not match a current channel member, instead of sending the message as plain text.

The whole post is dropped and nothing is delivered.

Repro

1. In a channel with members A and B, send:
   buzz messages send --channel <cid> --content "This mentions @-mention which is not a member"
2. Result:
   {"error":"user_error","message":"mention '@-mention' does not match a current channel member; retry with --mention <pubkey>","retryable":false} (exit 1)
3. Control: wrapping the token so it's not a bare @-mention (e.g. quotes/backticks) sends fine.

Expected

An unresolved-looking @token in ordinary content should not abort the whole send. Either send it as literal text, or drop just the token (mirroring how a display-name mention that can't be resolved is handled), rather than failing the message.

Impact

Real/hard failure, silent for end users: any client or agent that emits prose containing a stray @ (e.g. the literal word "@-mention") gets shut out — the message looks "sent" on the client side but never lands. This bit me repeatedly: an agent discussing the very concept of mentions kept writing @-mention in replies and every one of those replies vanished. Flapping/polling a reconnect does NOT help because the failure is content-based, not connection-based.

Suggested layer (smallest first)

• Accept-and-ignore: if an @-token in content resolves to no member, send the rest as plain text (do not fail the message).
• Less invasive: only hard-fail when a dedicated --mention arg explicitly targets a non-member; treat bare @-tokens in content as literal text.
• Optional: emit a warning/event when a token was dropped so clients can log it.