feat: structured interaction events — agent-postable buttons, forms, and polls

## Problem

Agents in Buzz can post messages, but they can't ask a structured question. Today, any agent workflow that needs an explicit human decision — "approve this payment," "pick one of three options," "fill in these two fields" — has to be improvised over free text or emoji reactions, then parsed back out of replies. That's lossy exactly where auditability matters most: the *decision*.

Coming from Slack, this is the one integration surface with no Buzz equivalent yet. Slack's Block Kit (buttons, select menus, modals) is what makes human-in-the-loop agent workflows practical there — an agent posts an approval card, a human clicks, the click is attributable and machine-readable. We're evaluating migrating a production agent system (payment-approval flows run by an agent, human clicks approve/reject/hold) from Slack to Buzz, and this is our only hard blocker.

Buzz is arguably in a position to do this *better* than Slack: a button click here could be a **signed event** — an attributable, non-repudiable decision by a keypair — rather than an ephemeral webhook payload.

## Proposal sketch (in Buzz's own idiom)

Two new event kinds, following the existing pattern in CONTRIBUTING → "How to Add a New Event Kind":

1. **`interaction.prompt`** — posted by any member (human or agent) into a channel/DM. Payload: prompt text + a typed schema of the requested input — `buttons` (n choices), `form` (fields with types), or `poll` (choices + close condition). Tags: who may respond (default: channel members), expiry, whether responses are public or sender-only.
2. **`interaction.response`** — signed by the responder, `e`-tagged to the prompt. Payload validates against the prompt's schema; the relay (or client) rejects mismatches.

Clients render kind 1 as buttons/form UI and emit kind 2 on interaction; clients that don't support the kinds degrade to showing the prompt text with reply-by-message fallback. Agents (via buzz-acp / buzz-cli / `buzz listen`) receive responses as ordinary events — no webhook infrastructure needed.

## Why signed interactions matter beyond parity

- **Auditable approvals:** "who approved this spend" becomes a signature chain, not a screenshot of a green checkmark.
- **Reputation-weighted or role-scoped responses:** because responders are keypairs, a poll can be scoped to a role, a channel, or holders of some attribute — primitives Slack can't express.
- **Agent↔agent negotiation:** structured prompts aren't only for humans; two agents can exchange typed offers/acceptances with the same mechanism.

## What we're asking

Mainly: is this direction on the roadmap, and if not, would a design proposal / PR along these lines be welcome? We'd rather align with maintainer intent than invent kinds unilaterally. Happy to write the fuller spec (schema validation rules, expiry semantics, privacy of responses) and prototype against a self-hosted relay.

Context: we run a Slack-integrated agent system (Hermes-based) for a software agency + talent community in Indonesia, and are evaluating Buzz as the shared workspace where employees, external community talents, and agents coexist. The BYOH Hermes preset landing in v0.5.0 removes our other blocker — thanks for that.