owner_only channel-add policy has no admin override, and the rejection doesn't say who can act — intended?

**Question / design clarification**

With `channel_add_policy = owner_only`, a community **owner/admin cannot add the agent to a channel** — only the agent's NIP-OA owner can. Is that intended? And if so, can the rejection say who *can* act?

**Where** (verified on `main` @ `ac4fa13`, 2026-08-01)

`crates/buzz-relay/src/handlers/side_effects.rs:421-434` — the kind:9000 third-party-add path checks the target's policy and requires `actor_bytes == owner_bytes`, with no elevated-role bypass, even though the surrounding code has already computed the actor's role and applies elevated-role checks for other operations.

**Observed**

```
relay error 400: invalid: policy:owner_only — only the agent owner can add this agent
```

…returned to a relay/community **owner** attempting to add a bot to a private channel.

**Why this may be intended**

Agent sovereignty: the entity that vouched for an agent decides where it participates, and an admin shouldn't be able to conscript someone else's agent into a channel. If that's the reasoning, it's a defensible line — it just isn't stated anywhere.

**Why it's worth revisiting**

- An admin cannot remediate an agent whose owner key is unavailable — there is no break-glass.
- The error names the policy but not the actor who can satisfy it (the owner pubkey is known at rejection time), which makes it hard to act on.
- Operationally it forces owner-key signing into provisioning automation that may otherwise never need the human key online.

**Suggested outcomes (any one of these resolves it)**

1. Confirm intended and improve the message: include the required owner pubkey in the error.
2. Allow community owners (not admins) as a documented, audited break-glass.
3. Add an explicit "owner delegates channel management to admins" flag on the kind:10100 policy record.

**Environment**

Self-hosted relay, `ghcr.io/block/buzz:main` @ `sha256:13ddb4c12f4c0b8147cece717a57013a45fdb1610bd072d7e383ac79a070ddd9`, `require_relay_membership = true`, `allow_nip_oa_auth = true`; Ubuntu 24.04.

**Related issues**

Searched open and closed — none found. Closest by keyword, but different problems: #3663 (`set-add-policy` clobbers the kind:10100 record), #3277 (mentionability of managed agents). Note: in our deployment this policy interacts with #4223 (NIP-OA owner never recorded on closed relays for direct members), which turns `owner_only` from "restrictive" into "nobody can ever satisfy it."

Start in crates/buzz-relay/src/handlers/side_effects.rs:421-434 and trace the kind:9000 third-party-add path, including the existing actor-role checks and owner_only rejection. First establish which of the proposed policy outcomes is intended; done means that decision is implemented or documented, with the rejection identifying who can act if owner_only remains restrictive.

Written by the indexing model from the issue text.