feat: per-community role capability policy (admin-managed clean experience for non-technical teams)

**Motivation**

Buzz is increasingly used as a Slack alternative by non-software, non-technical organizations (creative agencies, ops teams, etc.). These users expect a clean, curated experience where the entire topology — agents, compute, experiments — is set up and owned by an admin, and where non-admin members cannot accidentally perturb it.

Today every community member can open the Agents tab and the agents / compute / experimental settings sections, and there is no admin-managed boundary keeping the agent + compute surface curated.

**Proposed solution**

Add a per-community, per-role **capability policy**, configurable by the community owner. Default: current behavior (everything open) — no breaking change for existing communities.

Capabilities the owner can toggle per role:

- Enter the **Agents tab**
- See the **agents / compute / experimental** settings sections
- **Create/manage agents** (relay-enforced)
- Usage — @mention shared/owner-created agents — stays open by default, so members can still use the agents the admin has set up

**Implementation (Nostr-idiomatic)**

Following the project convention of modeling operations as Nostr events rather than new HTTP endpoints:

- A new owner-authored **community policy** event kind (alongside the `kind:39000` metadata family), carrying the role → capability map.
- Desktop reads it and filters the Agents tab + `SettingsView` sections (`SettingsView.tsx`) by the viewer's role. `SettingsView` currently hardcodes `sections: ["agents", "compute", "experimental", "mobile", "updates"]`.
- Relay reads it and enforces at ingest — reject member-authored agent-creation kinds (`30177` Managed Agent, `30176` Team) when that capability is off. Agent definitions are already owner-authored by design (`buzz-core/src/kind.rs`).

**Design constraint**

Relay enforcement requires the auth-pipeline mode. In pure-Nostr mode every NIP-42 connection receives the full scope set (`buzz-auth/src/scope.rs`), so member restriction is not enforceable there — this should be documented as part of the feature.

**Acceptance criteria**

- [ ] Owner can configure role → capability per community (default = open).
- [ ] Members in a locked-down community cannot open the Agents tab.
- [ ] Members never see the agents/compute/experimental settings sections.
- [ ] Members can still @mention shared/owner-created agents (usage open).
- [ ] Member-authored kind `30177`/`30176` rejected relay-side with a clear "admin-only" error in auth-pipeline mode.

Start by reading SettingsView.tsx, buzz-core/src/kind.rs, and buzz-auth/src/scope.rs to trace the existing settings, agent kinds, and auth-pipeline scope behavior. Then map the owner-authored policy event through desktop filtering and relay ingest for kinds 30177/30176, including the pure-Nostr limitation. Done means the listed acceptance criteria pass, including open agent usage and a clear admin-only rejection.

Written by the indexing model from the issue text.