Mention picker fails to coalesce local persona definitions with their running channel-member instances

## Summary

On Buzz Desktop 0.5.2, the `@` picker can offer account-synced persona-definition rows as `not in channel` while omitting the actual locally managed, running instances of those personas that are `bot` members of the current channel.

This reproduces on a **single Desktop installation**. It does not require a remote agent, a second device, or a missing local key.

The local store already contains the join needed to resolve the correct identity:

```text
instance.persona_id == persona.slug
```

The picker should coalesce the definition and instance, key membership and delivery by the instance pubkey, and use the persona only for presentation/configuration.

## Reproduction

1. Use one Buzz Desktop 0.5.2 installation connected to a self-hosted community.
2. Have locally managed agents running on that same Desktop and subscribed to a channel. In the reproduced case the channel contained the owner plus Grok, Claude, and Codex as `bot` members.
3. Confirm through the relay/channel-members UI that those three agent pubkeys are current channel members.
4. In the channel composer, type `@` or `@codex`.

## Actual behavior

- The picker omits the running Grok, Claude, and Codex instances.
- It offers persona rows such as Bumble, Fizz, and Honey.
- Those rows are labelled `managed by you · not in channel`.
- Typing `@codex` manually leaves plain text only. The published kind:9 has the channel `h` tag but no Codex `p` tag, so the harness is not triggered.
- The same Codex identity remains reachable through **Channel members → Codex → DM**, and that DM works.
- Restarting Desktop does not change the result.

## Expected behavior

- Current channel-member instances are offered and prioritized.
- Persona definitions linked to an existing instance are not shown as separate mintable/non-member candidates.
- Selecting Codex emits exactly one `p` tag for the existing Codex instance pubkey.
- No duplicate identity or harness is created or started.

## Local-state control

The affected installation's `managed-agents.json` contains 16 records:

- 8 persona-definition records with populated `display_name` and `slug`, but `pubkey: ""`;
- 8 running-instance records with populated `pubkey` and `persona_id`, but `display_name: null` and `slug: null`.

Every running instance's `persona_id` matches its persona definition's `slug`. All eight running instances are missing `display_name`.

For Codex specifically:

- the instance is active and configured to start with Desktop;
- there is no recorded startup error;
- its harness log shows a clean relay connection and subscription to the affected channel;
- the relay profile resolves correctly;
- the identity is not archived.

No full pubkeys, channel IDs, relay URLs, auth tags, or credentials are included here.

## Interpretation

This appears to be a candidate-assembly/coalescing defect:

1. Persona-definition rows are admitted even though they have an empty pubkey.
2. Their running instances are not enriched with the linked persona label/configuration.
3. Membership is necessarily keyed by the instance pubkey, so the empty-pubkey definitions render as non-members while the valid member instances disappear.

The safe join is already explicit in local state:

```text
instance.persona_id == persona.slug
```

The resulting candidate should retain the instance pubkey and runtime ownership; `persona.display_name` may provide the label. The join must not mint a new identity or infer that a remote instance is locally runnable.

## Scope boundaries

- Related to #3204, where the sanitized live reproduction was first posted: https://github.com/block/buzz/issues/3204#issuecomment-5140259539
- Distinct from #3676. That PR fixes the external-agent eligibility gate, while its author explicitly identified this single-install shape as a separate candidate-assembly defect at the persona/instance coalescing seam: https://github.com/block/buzz/pull/3676#issuecomment-5140851299
- Distinct from #3414. That issue covers a second device discarding an inbound `kind:30177` persona association and re-minting the persona. Here both definition and runnable instance already exist locally on one installation; the picker still fails to join them.

## Environment

- Buzz Desktop 0.5.2
- macOS
- One Desktop installation
- Self-hosted community
- Locally managed agents running through Buzz ACP harnesses

The issue names the channel composer’s @ picker and managed-agents.json but no implementation files or tests. Start by tracing picker candidate assembly and the local persona-to-instance join using instance.persona_id == persona.slug, then inspect membership matching by instance pubkey. Done means current local channel-member instances are offered once, linked persona definitions are coalesced, and selecting one emits exactly one instance p tag without minting an identity.

Written by the indexing model from the issue text.