Desktop resolves typed @Name against all known profiles, not channel members — a removed duplicate identity still gets p-tagged, so remove-member cannot repair a mention collision

## Environment
- Buzz Desktop v0.5.14, macOS (Darwin 25.4)
- Hosted relay `wss://buzz.ngnc.net`
- Same owner identity signed in on two Macs (which is how the duplicate agent identities arose — see #2648 / #6211; this issue is about the *repair path*, not the minting)

## Summary
When several agent profiles share a display name, Buzz Desktop resolves a typed `@Name` in a channel composer against **every profile it knows about**, not against the channel's current member list. So a duplicate identity that has been removed from the channel with `buzz channels remove-member` is still the one that gets p-tagged. The natural fix operators reach for (remove the ghost from the channel) therefore does nothing to mentions; the only working remedy today is renaming the ghost's display name.

The CLI behaves differently and, I think, correctly: `buzz messages send` resolves `@Name` against channel members and refuses to send on an ambiguous or non-member match.

## Steps to reproduce
1. End up with two agent identities sharing display name `Moneypenny` (in our case one live key `bebbcf8d…` and one dead key `5e03b576…` minted by a second Desktop whose runtime binary was missing — see #6211).
2. Confirm both are members of channel X. Remove the dead one:
`buzz channels remove-member --channel --pubkey 5e03b576…` → succeeds; `buzz channels members` shows only the live key.
3. From Desktop, in channel X, type `@Moneypenny hi` and send.
4. Inspect the event: the `p` tag is `5e03b576…` — the key that is **no longer a member**. The live agent is never woken.

## Expected
Desktop resolves a typed mention against the channel's members (as the CLI does), and a non-member is never p-tagged. If a name is still ambiguous *within the members*, surface that rather than picking silently.

## Actual
The removed identity is p-tagged. Removal from the channel does not change what the composer picks; only renaming the ghost's profile does.

## Why it matters
Every duplicate-identity report (#2648, #5583, #6211, #5542) ends with the operator trying to clean up. Removing the ghost from channels is the obvious cleanup and it looks like it worked (roster is correct) while mentions keep going to the corpse. That silent mismatch cost us most of a day of debugging.

## Related
#2648, #6211, #5583, #5542, #5264, RFC #5667

Start at the Desktop channel composer’s mention resolution and compare it with the `buzz messages send` path, which resolves names against channel members. Trace how the composer obtains profiles and current members, then verify that removed identities are excluded and ambiguous member names are surfaced rather than selected silently.

Written by the indexing model from the issue text.