Shared relay agents: let the requester observe their own turn's activity (decouple observability from NIP-OA ownership)

[eastriverlee]

Problem

Observer frames (kind 24200) are encrypted to the single NIP-OA owner. That fits personal desktop-managed agents, but for a shared server-side agent (harness-run, respond_to=anyone) it means the person who actually asked for the work can never see what the agent is doing with their request — they get a "Working" pill (until #1415 gates it) and silence, including when the agent dies mid-task (#2453).

Considered and rejected: multi-owner

Making every member an owner conflates control with visibility (owner commands !shutdown/!cancel/!rotate, draft flows) and fans single-recipient frame encryption out per member, against the 6/s / 90/min pacing budget (#2217).

Proposal: per-agent observer visibility policy

• owner-only — today's behavior, stays the default.
• requester — for each turn, the harness additionally encrypts that turn's observer frames to the author(s) of the triggering event(s). A turn batch has a small bounded author set, so fan-out is ~2 recipients, within existing pacing. Desktop decrypts frames addressed to the current identity and shows the activity panel for that turn. Because DMs are just two-member channels, this behaves identically in DMs and group channels: whoever asked can watch their request. This definition is intentionally mention-independent: harnesses running with --no-mention-filter (agents that decide relevance themselves) get the same semantics, because visibility follows event authorship rather than mention tags.
  Wider scopes (for example channel-member visibility) could be layered on later, but are intentionally out of scope here: requester keeps the existing single-recipient encryption model intact and only widens the recipient set per turn.

Control commands and draft flows remain owner-only under every policy.

Acceptance criteria

1. With --observer-visibility requester, the author of a triggering event can open the agent's activity panel and watch that turn live; other members cannot.
2. The owner continues to see all turns. Owner-only agents behave exactly as today.
3. Works identically for DM turns and channel turns; multi-author batched turns are visible to each batch author. Frames stay scoped per turn (channel_id/session_id/turn_id), so concurrent turns render independently.
4. Control commands and draft approval remain owner-only regardless of visibility policy.
5. Frame pacing budgets hold (bounded per-turn recipient set, no member-count fan-out).

Context

Self-hosted single-company relay; the agent is a shared assistant the whole staff mentions. Related: #2603/#2605 (shared relay agents mentionable), #2646 (composer live-activity experiment), #1415 (working-pill ownership gating), #2453 (silent agent death), #2217 (observer frame pacing).

[MPIsaac-Per]

I'm building a fleet view on top of kind:24200 and presence right now. Owner-only means that consumer either holds the owner key or renders nothing, so a read-only dashboard ends up carrying the most privileged key in the workspace. I don't need the whole stream, just the turns my side triggers, and the requester policy covers that with the consumer's own keypair. Owner-only still seems like the right default for shared agents. Requester as a per-agent opt-in would let read surfaces stay read surfaces.