feat(relay): channel-gated agent work status kind (NIP-AW, 30181)

[LucasMoskun]

Problem

Buzz Desktop shows a live "Working…" badge from ephemeral typing indicators, but there is no persistent, queryable answer to "what is this agent doing right now?" Operators today either SSH into agent hosts or run side-channel collectors to get a live fleet view. The buzz-acp harness already sees everything it drives — turn lifecycle, tool calls, streaming — it just never tells anyone.

The privacy bar this PR holds: an agent's work status should be exactly as private as the channel it describes. Anyone who can read the channel's messages may see its status; nobody else can, enforced server-side. Kind 30315 (NIP-38) cannot meet that bar — it is a global-only kind on Buzz relays, readable by any authenticated relay member. This PR deliberately stays relay-gated plaintext (like channel messages themselves); encrypted lanes remain NIP-AO's job and out of scope here.

What this adds

A new parameterized-replaceable kind 30181, KIND_AGENT_WORK_STATUS (spec: docs/nips/NIP-AW.md), with h = d = channel UUID:

• buzz-core: kind constant + registry entry.
• buzz-relay (registration only — no new access-control machinery): MessagesWrite scope; requires_h_channel_scope so writes and reads inherit the existing NIP-29 channel-membership gate; an envelope check rejecting d ≠ h (a divergent d would allow multiple snapshots per channel or cross-channel coordinate collisions); metrics label. NIP-33 replacement keeps at most one live snapshot per (agent, channel) — a status lane, not a history log.
• buzz-acp: opt-in --public-status / BUZZ_ACP_PUBLIC_STATUS flag. A second consumer of the observer bus projects frames into signed status events: turn status, model id, timestamps, and tool-call titles only. Tool arguments, file paths, prompts, streamed text, and error messages never enter the payload — the projection is whitelist-shaped by construction and unit tests assert secrets stay out. Publication is paced (urgent on start/complete/error, 5 s floor otherwise, 3 s budget) and publish failure is never fatal to the turn.

Any channel-authorized client can then render live agent lanes with one REQ — no collectors, no new HTTP surface, matching the "prefer Nostr events" guidance in CONTRIBUTING.

Testing

• Unit: cargo test -p buzz-core -p buzz-acp green (262 / 811); -p buzz-relay green except 8 pre-existing api::media/api::admin failures that fail identically on untouched main in this environment.
• New relay unit tests: scope/requires_h/global-only registration, d/h mismatch + non-UUID + missing-d rejection.
• New acp unit test pins the envelope (kind 30181, h and d = channel).
• Live e2e (test_agent_work_status_channel_gating, run against a local relay + Postgres + Redis): member write accepted → d ≠ h rejected → missing h rejected → non-member write rejected (restricted: not a channel member) → member REQ returns exactly the one snapshot → non-member REQ is answered with CLOSED "restricted: not a channel member".
• cargo fmt --check and cargo clippy --all-targets clean on the four touched crates.

Related PRs

Closest existing work found: #446 (original NIP-38 kind:30315 support — this PR exists because 30315 is global-only), #5098 / #4769 (desktop/diagnostic observability — complementary, different lane). None add a channel-gated status kind.

🤖 Generated with Claude Code