Relay logs omit event.kind, making publish failures indistinguishable from success

[blissfire]

Describe the bug

The relay's HTTP bridge log line records route and status but not the event kind:

{"message":"HTTP bridge request","pubkey":"d5b0ab11…","route":"/events","status":200,"accepted":true}

Typing indicators (kind 7) and their deletions (kind 5) travel the same /events route as real messages (kind 9). So every agent turn produces accepted:true lines whether or not a message was actually sent.

This is a trap rather than a cosmetic gap. Two independent debugging efforts — a previous session and my own — both concluded "the agent published successfully, so the transport works" from exactly these lines. It was false both times. The events were typing indicators; the agent had sent nothing.

The only way to establish the truth was to bypass the logs and query Postgres directly:

select created_at, kind, substring(encode(pubkey,'hex') for 8), substring(content for 70)
from events order by created_at desc limit 20;

Steps to reproduce

1. Have an agent receive a message and end its turn without calling buzz messages send (see the companion issue on silent prose replies — easy to trigger with a small model).
2. docker logs buzz-relay-1 | Select-String '<agent pubkey>'
3. Observe several route:"/events", status:200, accepted:true entries.
4. Query the events table — no kind 9 exists. The accepted events were kinds 7 and 5.

Expected behavior

The log line should include kind — and ideally channel_id — so that "the agent published a message" and "the agent published a typing indicator" are distinguishable without a database query.

Version and platform

• Buzz version: local dev build, block/buzz @ 318fbf896 (dockerised relay)
• OS: Windows 10 / Docker Desktop
• Stack: Postgres 16, Redis, MinIO

Logs / additional context

Real example. The agent sent no message at all during this window, yet the log reads as unambiguous success:

05:39:25.069Z  route:"/events"  status:200  accepted:true   ← kind 7 (👀 seen)
05:39:25.075Z  route:"/events"  status:200  accepted:true   ← kind 7 (💬 typing)
05:39:44.339Z  route:"/events"  status:200  accepted:true   ← kind 5 (delete)
05:39:44.343Z  route:"/events"  status:200  accepted:true   ← kind 5 (delete)

One additional field would have collapsed a two-day investigation into a few minutes. It would also make the existing fan-out diagnostics far more useful, since those currently can't tell you what was fanned out either.