Desktop 0.5.20: an agent that created the channel (member role `owner`) is missing from @mention autocomplete; the same agent is mentionable where its role is `bot`

## Summary

On Desktop 0.5.20, an agent that **created** a channel via the CLI (`buzz channels create`) does not appear in that channel's `@`-mention autocomplete, and the human owner cannot mention it. The *same* agent identity, same machine, same relay, is mentionable in channels where its member role is `bot`.

The only difference we can find between the two groups of channels is the member's **role**: `buzz channels create` records the creator as `owner`, and agent members with role `owner` appear to be filtered out of the mention picker.

This is self-inflicted by a normal flow: an agent that organizes work by creating a channel per task makes itself unmentionable in every channel it creates.

## Environment

- Buzz Desktop 0.5.20, macOS (Apple Silicon)
- Self-hosted relay
- 4 agents, all **locally managed on the same machine as Desktop** (present in `agents/managed-agents.json`), run via the bundled ACP runtime. This is not the remote/cross-owner topology of #4833 / #6022.

## Observation

One agent identity, 10 channels:

| agent's member role | channels | human can `@`-mention the agent in Desktop |
|---|---|---|
| `bot` | 3 (created by the human owner) | yes — works every day |
| `owner` | 7 (created by the agent itself with `buzz channels create`) | no — the agent is not offered in the picker |

The owner's report: "`@` 를 눌러도 에이전트가 안 나온다" (pressing `@` doesn't list the agent) in exactly the second group.

## The relay side is fine — it is the picker

Membership and display-name resolution are role-independent. In a throwaway private channel where the agent's role was `owner`, another identity sent a message whose body only contained the agent's display name, with no explicit mention flag:

```console
$ buzz channels members --channel
owner
admin

$ printf '%s\n' '@ test' | buzz messages send --channel --content -
{"accepted":true,"event_id":"...","mention_pubkeys":[""],"message":""}
```

The relay resolved the name to the agent's pubkey and delivered the mention while the role was `owner`. So the omission is in the Desktop mention picker, not in membership or resolution.

## The workaround has a real price

Lowering the agent's role `owner` → `bot` makes it mentionable, but as `bot` the agent can no longer manage the channels it creates (measured on 0.5.20):

- `buzz channels remove-member …` → `400 invalid: actor not authorized`
- `buzz channels update --name … / --visibility …` → `400 invalid: actor not authorized for name/about/archived/visibility/ttl changes`

And an identity cannot change **its own** role — the CLI omits the `p` tag when the target is the signer:

- `buzz channels add-member --channel --pubkey --role bot` → `400 invalid: missing p tag`

So a second privileged identity must be kept in every channel just to demote the creator afterwards, and the demotion has to happen *after* all membership setup, because it is one-way from the agent's side. Net effect today: an agent can either manage the channels it creates **or** be mentionable in them, not both.

## Expected

The mention picker should offer any channel member that can receive a mention — from relay membership — regardless of that member's role. At minimum, an agent member with role `owner`/`admin` should not be hidden.

Alternatively (or additionally), `buzz channels create` could avoid putting an agent creator into a role that hides it from the picker.

## Repro

1. From an agent identity: `buzz channels create --name t --type stream --visibility private`.
2. Add the human owner as a member.
3. In Desktop, as the human, type `@` in that channel — the agent is not listed.
4. Have a third privileged identity run `buzz channels add-member --channel --pubkey --role bot`.
5. Type `@` again — the agent is listed.

## Related

#4833 (picker validates against the local managed-agents store instead of relay membership) looks like the closest mechanism; this report adds a discriminator that does not involve remote or cross-owner agents — only the member's role changes. Also related: #6022, #6032, #3277, #2699.