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.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is bc006f67087b049e2f9c4d8a2f26faceff628225...324373d74760f827068674bfc15345d796c25767.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 324373d74760f827068674bfc15345d796c25767 to authorize a new review.
Any previous review applies only to its recorded range.

[LucasMoskun]

Rebased onto current main — the merge conflict is resolved and all checks are green (full unit suite passing locally as well). No functional changes since the original submission.

@wpfleger96 you seem to be the most active in buzz-acp and the NIP docs this touches — would appreciate a review when you get a chance. Happy to adjust the approach (kind number, gating, event shape) if the direction needs tweaking.