Feature: relay-transported observer traces so remote/cloud buzz-acp agents can show the thinking & tool-call bubble

## Summary

Buzz Desktop's expandable **thinking / tool-call bubble** (the "info bubble" that shows an agent's reasoning trace and tool calls) currently only renders for agents whose `buzz-acp` process Desktop talks to over a **local ACP handle**. A **remote / cloud-hosted `buzz-acp`** agent — one that connects to the relay from its own host and never runs as a local subprocess of the viewer's Desktop — cannot populate that bubble, even when the agent correctly emits ACP `agent_thought_chunk` and `tool_call` / `tool_call_update` session updates.

Request: define a **relay-transported observer-trace channel** so remote agents can surface the native thinking/tool bubble **without requiring the viewer's machine to act as the local ACP broker.**

## Motivation

Self-hosted / always-on agents are a first-class use case (see also #2663). A user running an agent as a cloud `buzz-acp` sidecar sees its final `kind:9` replies, but gets **none** of the reasoning/tool-call observability they get from a locally-spawned agent. This makes remote agents strictly second-class in the UI, and pushes authors toward stuffing reasoning into the message body as a workaround.

## Evidence / current behavior

Investigated with a local agent (bubble renders) and a remote cloud `buzz-acp` agent (bubble never renders), same relay, same DM channel:

- **Relay carries no trace events.** Querying the channel's full event log (`buzz messages get --kinds …`) and `buzz feed get --types agent_activity` returns **only `kind:9` messages** (plus `kind:7` reactions) — for *both* agents, including the local one whose bubble renders fine. So the trace that feeds the bubble is **not** transported over the relay as stored events.
- **The local agent's bubble is sourced from a direct local ACP handle** between Desktop and the `buzz-acp` subprocess it spawned — not from anything on Nostr.
- **The remote agent emits traces correctly**, verified in its ACP adapter: provider reasoning deltas are wired to `agent_thought_chunk` session updates, and tool calls to `tool_call`/`tool_call_update`. Those updates are produced inside the remote `buzz-acp → agent` process, but that process is not attached to the viewer's Desktop, so they have nowhere to go.
- The remote sidecar runs with `BUZZ_ACP_RELAY_OBSERVER=true` and the binary contains observer-frame code, but from inside the running pod there were **no stored ephemeral events, no observer logs, and no confirmable outbound observer frames** — so it's unclear whether this flag already publishes relay observer traces, and if so in what form and why Desktop doesn't render them.

## Open questions for maintainers

1. Does `BUZZ_ACP_RELAY_OBSERVER=true` already publish observer frames (thought / tool-call updates) to the relay? If so, what event kind/shape (ephemeral 2xxxx?), and how are they associated with the response event?
2. If such frames exist, does Buzz Desktop render the bubble from them, or only from a local ACP handle? Is rendering gated on the agent being **owner-authorized** (i.e. messages carrying a NIP-OA `auth` tag / `BUZZ_AUTH_TAG`)? A remote agent without an auth tag is treated like a member — does that suppress the bubble even if traces are present?

## Proposed solution

- Define (or document, if it exists) a **relay observer-trace channel**: `buzz-acp` optionally publishes `agent_thought_chunk` and `tool_call`/`tool_call_update` frames as **ephemeral events** tagged with the response event id, gated behind an explicit opt-in flag (privacy — reasoning traces should never be published by default).
- Have Buzz Desktop render the thinking/tool bubble from those relay observer frames for **remote** agents, with the same association-to-response-message it uses for local agents.
- Clarify the interaction with owner authorization: if the bubble is (or should be) gated on an `auth` tag, document that a remote agent needs an owner-minted `BUZZ_AUTH_TAG` deployed to its sidecar for traces to render.

## Constraints / notes

- Must be **opt-in** and privacy-preserving; exposes provider-supplied reasoning summaries only, not any hidden chain-of-thought.
- Should work **without the viewer's machine acting as a broker** — the whole point is cloud/always-on agents.
- Related: #2663 (external non-ACP agent systems).