Proposal: an optional activity label in typing indicators (kind 20002)

## Summary

Typing indicators (kind 20002) tell members *that* someone is active, but never *what* they are doing. For agent members (buzz-acp harnesses, custom bots), a short activity label in the typing row — `Twaky is typing — reading the Journal…` — would make agents noticeably more transparent without any new UI surface.

## Motivation / use case

We run a personal agent (Twaky) inside Buzz communities. While a turn runs (15 s to several minutes) the channel only shows "Twaky is typing…". We currently publish a per-tool status as a NIP-38 user status (kind 30315); it works with zero upstream change, but renders subtly (emoji + tooltip next to the agent's name) — away from where users actually look during a turn: the typing row.

An optional activity label on the typing event itself solves this exactly where users look, for any agent harness, with no new surface.

Closest existing work I found: #2646 (live agent activity in status pills — a different, richer surface; this proposal is deliberately much dumber). No duplicate found in open issues/PRs.

## Proposal

Convention: a typing event whose `content` is non-empty carries a short activity label (publishers SHOULD keep it under ~80 characters). Clients rendering the typing row append it when exactly one member is typing:

- `Alice is typing — reviewing the quarterly report…`
- Empty content (what every publisher sends today): unchanged `Alice is typing…`.

Why `content` rather than a new tag:

- NIP-38 precedent: user-status text already rides in `content` (kind 30315).
- No structural change anywhere: the relay already fans ephemeral events out verbatim (the PR adds a conformance assertion that typing content round-trips through pub/sub).
- Mobile can adopt later with a one-line read.

What this is NOT:

- **Not a change to buzz-acp**: it cannot know its agent's current activity, and harnesses that publish their own labeled typing can already own the indicator via `--no-typing`. A static configured label could be a follow-up if you want one.
- **Not ACP-derived activity**: that overlaps with the agent-activity work already in flight (#2646); this works for *any* publisher, including non-ACP bots.

## Scope of the PR I intend to send

- Desktop: parse + bound the label in `useChannelTyping`, thread it to `TypingIndicatorRow` (rendered in the single-typer case only), mock-bridge support, E2E coverage.
- Conformance: assert a typing event's `content` round-trips through pub/sub.
- Docs: `NOSTR.md` and the `kind.rs` comment for `KIND_TYPING_INDICATOR`.
- Mobile: unchanged (ignores `content` exactly as today); happy to include the parity one-liner in the same PR if you prefer.

Backward compatibility is total: every existing publisher sends empty `content`, every current client ignores it, and old clients keep rendering today's label.

Happy to adjust the convention (tag vs `content`, length cap, multi-typer behavior) before I finalize.

Start with useChannelTyping and TypingIndicatorRow to trace how typing events reach the desktop typing row, then inspect the mock bridge and existing E2E coverage. Review kind.rs and NOSTR.md for the typing-event definition and documentation expectations. Done means non-empty content is bounded and shown for one typer, empty content remains unchanged, pub/sub round-trips it, and the listed coverage passes.

Written by the indexing model from the issue text.