Workflow `@mentions` silently fail to notify when two channel members share a display name — no `p` tag, no warning, no log line

## Summary

When a channel contains two members with the same display name, a workflow's
`send_message` containing `@Name` resolves to nothing: the posted event carries no
`p` tag for the intended agent, so the agent is never notified and never wakes.

The message still posts and **looks completely correct in the channel**. There is
no error, no warning at any point, and nothing in the harness log — the agent
simply never responds.

I understand ambiguous `@Name` being treated as presentation-only is intended
(`buzz messages send --help` documents it). The problem is that nothing surfaces
it, and the Desktop UI permits the situation that triggers it.

## Reproduction

1. Create an agent named `Probe`, add it to a channel, start it.
2. Ensure a **second** member with display name `Probe` is in the same channel —
in my case a stale identity from an earlier agent, which the UI listed happily
as a second `Probe · agent`. (With the built-in agents you get this for free:
sign out and back in once, and there are two of each.)
3. Create a workflow that posts `@Probe ` on a `message_posted`
trigger.
4. Fire the trigger.

**Result:** the workflow posts. The agent does nothing — no reaction, no turn, no
log entry. Verified over 24s, 64s, and again after a full application restart.

**Then remove the duplicate member and repeat step 4** — the agent responds within
9 seconds.

(The agent's `respond_to` was set to `anyone` throughout both halves of this test,
via the `managed-agents.json` workaround for #2501 — a workflow posts under its own
pubkey, so that setting is separately required. It was not the variable here: it
was identical before and after, and only the duplicate member changed.)

## The difference is visible only in the event tags

Same workflow, same text, same channel — before and after removing the duplicate:

```
# two members named "Probe"
WORKFLOW p=['3cd8a94f…'] @Probe PROBE-3-PAYLOAD … ← owner only; agent never notified

# one member named "Probe"
WORKFLOW p=['3cd8a94f…', '8d241e8e…'] @Probe PROBE-3-PAYLOAD … ← agent tagged; wakes in 9s
```

The only way to tell the two apart is to query the relay and inspect the `p` tags.
Nothing in the Desktop UI, the channel view, or the harness log distinguishes
them.

## Why this is worth guarding

This is the sole mechanism by which a workflow can reach an agent — workflows
cannot invoke agents directly (per ARCHITECTURE.md, that bridge exists only in
buzz-acp), so an `@mention` is the only route. A silently-dropped mention means
**the workflow appears to run correctly while doing nothing at all**.

**It is also not something the user has to do wrong.** Buzz produces this state on
its own: each sign-out/sign-in cycle re-provisions the built-in agents with new
keypairs while leaving the previous ones in the channel. After three cycles one of
my channels held nine bot members under three display names — so `@Bumble` there
now notifies nobody, silently. Filed separately as a companion issue; that one is
the cause, this one is why it's invisible.

Diagnosing it took several hours and required eliminating agent state, channel
membership, authentication, and permissions (#2501) first, because none of those
produce a distinguishable symptom either.

## Suggested fixes, cheapest first

1. **Log it.** One WARN from the workflow engine — `@Name ambiguous in channel X,
N matches, no notification sent` — would make this a two-minute diagnosis.
2. **Warn at workflow save.** The channel is known at creation time; an `@Name`
in a step's `text` that matches 0 or ≥2 members could be flagged in the editor.
3. **Warn on duplicate display names** when adding a member/agent to a channel.
4. Consider allowing a workflow step to target a **pubkey** explicitly, the way
`buzz messages send --mention ` already does. That would make
workflow → agent routing robust regardless of naming.

Point 4 would be the real fix for automation: names are a human affordance, and
a workflow shouldn't depend on them being unique.

Environment: Buzz Desktop v0.5.3, macOS, hosted community, Claude Code harness.
Happy to provide the full before/after event dumps.