message_posted workflow triggers never execute on hosted relay (webhook/schedule/manual triggers work)

## Summary

On a hosted Buzz relay (`*.communities.buzz.xyz`, checked 2026-08-02), workflows with `trigger: on: message_posted` never execute, while webhook-triggered, scheduled, and manually-triggered workflows on the same relay/channel run fine. Because run history is also invisible to clients (see below), a dead trigger is indistinguishable from a working one, which makes this very hard for users to self-diagnose.

## Environment

- Hosted relay on `communities.buzz.xyz` (deployed version unknown to me — NIP-11 doc carries no version field)
- Buzz Desktop 0.5.3 (macOS) and `buzz` CLI from the same bundle
- Could not verify against OSS HEAD locally (no Docker on this machine), so this may be deployment drift rather than a bug at `main` — flagging either way since hosted users can't tell the difference.

## Repro (CLI, ~2 min)

1. As a channel member, create a minimal message-triggered workflow with an observable in-channel action:

```yaml
name: engine_probe
enabled: true
trigger:
"on": message_posted
filter: 'str_contains(trigger_text, "probe-phrase-7793")'
steps:
- id: react
action: add_reaction
emoji: eyes
```

`buzz workflows create --channel --yaml "$(cat probe.yaml)"` → accepted, workflow id returned.

2. Post a kind:9 channel message containing `probe-phrase-7793`.
3. Wait. Expected: 👀 reaction on the message (via the relay workflow sink). Actual: nothing (checked with `buzz reactions get --event ` over ~10 minutes).

## What DOES work on the same relay

- **Manual trigger**: `buzz workflows trigger --workflow ` on the same probe workflow → `accepted`, `run_id` returned.
- **Webhook-triggered workflows**: a `trigger: on: webhook` workflow with a `send_message` step has fired repeatedly on this relay (relay-signed kind:9 messages with the `buzz:workflow` tag are present in channel history).
- Workflow saves, updates, deletes, and list queries all behave normally.
- The SEC-006 gates behave as documented (e.g. `forbidden: workflows with call_webhook actions require the owner or admin role` for non-admin authors) — the probe above deliberately avoids `call_webhook` and is owned by a member whose role passes `owner_authority_allows(role, false)`.

## Where I looked in the source

`dispatch_persistent_event` (`crates/buzz-relay/src/handlers/event.rs:533`) spawns `workflow_engine.on_event(...)` for stored kind:9 events, and `WorkflowEngine::on_event` reads enabled workflows from the DB (10s cache) before evaluating `trigger_matches_event` / `should_fire_workflow`. I couldn't find a path where the probe above should be skipped, which is why I suspect the hosted deployment predates or diverges from this wiring — but I can't confirm the deployed version.

## Related papercut that made this much worse

`buzz workflows runs` always returns `[]` by design (`crates/buzz-cli/src/commands/workflows.rs:63` — runs live in the `workflow_runs` table and kinds 46001–46003 are never emitted), and the Desktop equivalent returns a hard-coded empty list (`desktop/src-tauri/src/commands/workflows.rs`, `get_workflow_runs` TODO). So users have zero signal on whether any workflow ever fired. Even just emitting run-started/run-failed events (or a REST read) would have made this a 5-minute diagnosis instead of an afternoon.

Happy to provide more detail or run further probes on the hosted relay if useful.