Self-hosted findings: multi-value #h dropped by /query, workflow deletion ghosts, silent member-update discard, panic on social-post reaction

Self-hosted community on current `main` (relay image digest `b4148c43…`, Desktop latest release, closed relay: auth token + membership required). Four related findings from a day of production use — three have minimal repros and local patches (diff available, happy to open PRs).

### 1. `/query` bridge drops multi-value `#h` filters → Desktop Workflows tab always empty

`extract_channel_from_filter` (`crates/buzz-relay/src/api/bridge.rs`) only resolves the channel when the `#h` filter has exactly **one** value (`vs.len() == 1`), returning `None` otherwise — the query then yields an empty result set silently. The Desktop's Workflows overview batches all member channels into a single filter (`get_channels_workflows`, "replaces the per-channel fanout"), so the tab permanently renders "No workflows yet" even though the relay stores and executes the workflows.

Repro (NIP-98-signed `POST /query`):

```
{"kinds":[30620],"#h":[""]} → 200, N results
{"kinds":[30620],"#h":["",""]} → 200, 0 results
```

NIP-01 defines multiple values in a tag filter as OR. Local fix: expand a multi-value `#h` filter into one single-channel filter per value before processing, so every downstream membership/authorization check runs per channel unchanged.

### 2. Deleting a workflow leaves its kind:30620 event alive → ghost cards in the list

The NIP-09 deletion side-effect for `KIND_WORKFLOW_DEF` (`handlers/side_effects.rs`) removes the engine row (`delete_workflow_for_owner`) and invalidates the cache, but never touches the stored 30620 event. Since the Desktop lists workflows from those events, deleted workflows keep showing forever (and, combined with finding 1's fix, reappear after every refetch). Local fix: soft-delete (`deleted_at = now()`) the definition events for the deleted workflow's `d` tag in the same side-effect.

### 3. Workflow update by a plain member is accepted then silently discarded

A `kind:30620` update signed by a member who is not the workflow owner (nor admin) gets `accepted: true` from the relay, but neither a new event version nor an engine-table update is materialized. The client believes the edit succeeded; execution keeps using the old definition. Expected: either reject with an explicit error or materialize. (Observed while an agent identity tried updating a workflow it didn't own; owner/admin updates work.)

### 4. Reaction to a social post panics the relay task → client sees 502

Reacting (kind 7) to a channel-less kind:1 social post hits `channel_id.expect("reaction path has channel")` at `handlers/ingest.rs:2733` — the comment above it says "channel_id is always Some here", which is false for social reactions:

```
thread 'tokio-rt-worker' panicked at crates/buzz-relay/src/handlers/ingest.rs:2733:51
```

The reaction IS persisted (panic happens in post-persist tracing), the client gets `502 Bad Gateway`, and every retry panics again. Local fix: `channel_id.unwrap_or(Uuid::nil())` for the trace label.

---

Combined patch for 1, 2 and 4 (applies on `main` @ `ac4fa13`) is running in our production relay; glad to split it into PRs if useful. Workflows experiment is enabled under Settings → Experiments. Thanks for Buzz — the agent-native design is excellent to operate.