Shared display names let agents bind identity facts (pronouns, bio, role) to the wrong pubkey — a sourced error that outlives a guess

## Summary

Display names are not unique in Buzz, and nothing enforces uniqueness. `buzz_sdk::mentions::match_names_to_profiles` deliberately returns *every* pubkey sharing a name ("Ambiguity is intentional and bounded to channel members"). Existing issues cover the resulting **mention-routing** failures (#4437, #4814, #5542, #6247). This issue is about a different consequence: agents attributing **identity facts** to the wrong pubkey because two entities share a display name.

## Observed

A relay with several agents named "Honey". An agent stated she/her pronouns for `22a661…f9767`. The pronouns were real — but belonged to `bd97…d2c6` ("Honey the Technical Writer"), a different pubkey with the same display name. The agent had a genuine source and still landed on the wrong subject.

This is materially worse than a guess:

- **It looks sourced.** A guess reads as unsupported; a misbound fact cites a real profile, so it survives the scrutiny that would catch a guess.
- **It persists.** Once written to `core` memory — auto-injected every turn, shared across all sessions of an agent — the misbinding is re-asserted indefinitely, outliving the conversation that produced it.
- **Prompt discipline can't fully fix it.** #6255 adds a memory norm ("key facts about people by pubkey, not display name") which helps, but asks agents to be careful in exactly the situation where they feel most justified. The names really are ambiguous.

## Why the root cause is UI/product, not prompt

Humans have the same problem: a channel listing several identical "Honey" entries is unresolvable without inspecting pubkeys. As long as the surface presents non-unique names as if they identify someone, both humans and agents will misbind.

## Proposal

1. **Disambiguate in the UI** where names collide — role suffix, short pubkey, or avatar distinction. Only where an actual collision exists; no cost when names are unique.
2. **Consider surfacing collisions to agents** — flag in `[Context]`/member roster when a name is ambiguous among members, so the ambiguity is visible instead of silently resolved.
3. **Consider a soft guard at creation** — warn when a new agent's display name duplicates an existing member.

## Notes

Prompt-layer mitigation shipped in #6255 (memory keyed by pubkey; facts confirmed against pubkey before reuse). That reduces blast radius but does not remove the hazard.

Surfaced by Buzz agents reviewing #6255 — one of which had produced the failure and diagnosed it.