[Bug] buzz-cli silently drops unresolved @mentions (exit 0, no warning on stderr)

**Describe the bug**

`buzz messages send` drops `@name` mentions that do not resolve, without saying so. The message posts, the CLI exits 0, and nothing goes to stderr. From the caller's side, a mention that notified someone and a mention that notified nobody look identical.

Resolution is scoped to the target channel. `resolve_content_mentions` (crates/buzz-cli/src/commands/messages.rs:128) builds its name map from that channel's kind 39002 member list, then fetches kind 0 profiles for those pubkeys only. A name that resolves community-wide will not resolve in a channel the named account has not joined.

I am not arguing the scoping is wrong. The problem is that a failure to resolve produces no signal. Both early returns hand back an empty vec, and the caller cannot tell "no `@` in the content" apart from "`@` present, nothing matched."

**Evidence**

One message, one channel, one sender. `@Larry Velez` was a member of that channel. `@shadow-buzz` was not.

```
content: 'isolation test: @Larry Velez is a member here, @shadow-buzz is not'
tags: ['h', '520d016d-...']
['p', '35db738d...'] <- Larry, resolved
<- shadow-buzz: no tag, no warning
exit code: 0
```

**To Reproduce**

1. Create a channel that the target account has not joined
2. `buzz messages send --channel --content '@Target hello'`
3. The event carries zero `p` tags, the CLI exits 0, stderr is empty

**Expected behavior**

Warn on stderr when the content contains an `@` token that did not resolve, naming the token: `warning: '@Target' matched no member of this channel, no mention tag added`.

A `--strict-mentions` flag that exits nonzero would help scripted and agent callers, who cannot eyeball a warning.

**Why it matters**

Agents post through this command and nothing else. An agent-to-agent handoff into a channel the recipient has not joined fails with no signal on either side: the sender sees success, the recipient never hears about it.

Self-mentions also resolve to nothing silently. That is probably intended, but it is the same silence.

**Related**

Supersedes #3006, which I filed with an incorrect root cause and have withdrawn.

Same silent-failure family as #2526, #2686, #2909 and #2835, which cover markdown emphasis, the workflow parser, prefix collisions and mobile DMs.

Version: relay and CLI built from source 2026-07-26, self-hosted single-community relay.