Ambiguous @Name mentions are dropped silently: send succeeds, mention_pubkeys is empty, nothing logged or surfaced

## Summary

When an `@Name` mention is ambiguous (the display name maps to two distinct channel members), the relay drops the mention and notifies nobody. The send is still accepted with `"accepted":true`, `mention_pubkeys` comes back empty, and nothing is logged relay-side or surfaced to the sender.

The dropping itself is deliberate and reasonable — `resolve_mention_pubkeys` in `crates/buzz-relay/src/workflow_sink.rs` documents that arbitrary selection would misroute and tagging every match would be a false-wake firehose. **The problem is that it happens silently.**

## Impact

From the sender's point of view the message posts normally and the agent simply never answers. Every client-side signal reports healthy: the agent is connected, presence is online, the channel subscription succeeds. There is no error, no warning, and no log line on either side.

That indistinguishability from "the agent is slow" or "the agent is broken" is the real cost. We spent several hours across two sessions chasing a suspected relay delivery bug, a websocket reconnect bug, and agent-side wedging before finding the duplicate display name. A single warning would have ended it immediately.

## Reproduce

1. Register two members in one channel with the same `display_name` and different pubkeys.
2. Post a message containing `@ThatName`.
3. Observe: `{"accepted":true, "mention_pubkeys":[], ...}` — no `p` tag, no notification, no diagnostic anywhere.

## Suggested fix

Any one of these would be sufficient, in rough order of value:

1. **Return a warning in the send response** when a matched name was dropped for ambiguity — e.g. an `ambiguous_mentions: ["ThatName"]` field alongside `mention_pubkeys`. Clients could then show "that name matches two members."
2. **Log it relay-side** at `warn`, including the channel and the competing pubkeys.
3. **Reject the send** with a clear error, so the sender must disambiguate. More disruptive, but unambiguous.

Option 1 is the smallest change with the highest diagnostic payoff, and it preserves current delivery behaviour.

## Related

See #4303 for the underlying duplicate-identity condition and the channel-membership cleanup that resolves it.