perf(relay): bounded-concurrency multi-filter query execution (S2)

[tlongwell-block]

What & why

Follow-up S2 reserved by #1452's follow-up list; sequenced after #1418 (merged, 7da936ff). Part of the buzz-gui-performance arc.

NIP-01 multi-filter requests (POST /query catch-all pass in api/bridge.rs, WS REQ historical delivery in handlers/req.rs) executed one db.query_events await per filter, serially. A K-filter request paid K sequential DB round trips — the structural cost behind get_channels' N per-channel last-message filters and any client-side request batching (which otherwise only saves HTTP RTT + NIP-98/auth tax, not DB time).

Design

Both loops split into three phases:

1. Construct — pure query construction + validation, in filter order (bridge: access-scope skips, before_id 400, page offsets all decided here).
2. Query — db.query_events via futures_util buffered(FILTER_QUERY_CONCURRENCY = 4) — bounded, order-preserving concurrency.
3. Post-process — strictly in original filter order.

Because buffered (not buffer_unordered) yields in input order, phase 3 is byte-identical to the old serial loop:

• NIP-01 OR/dedupe order: seen_ids insertion order = filter order; an event failing filter A stays eligible for filter B.
• Per-event access gates unchanged and still result-level: event_in_accessible_channel, filters_match, reader_authorized_for_event, author-only.
• Conformance trace rows emitted in filter order.
• First-error-wins semantics preserved (WS: EOSE + return on first failed filter; bridge: 500 on first DB error).
• Special-pass filters (feed_types, depth_limit, search) handled in earlier loops — untouched. Per-filter LIMITs unchanged.

One deliberate edge shift (bridge only): before_id validation (400) for a later filter now surfaces before any earlier filter's DB query runs — deterministic client errors now always precede transient DB errors. No caller depends on the old interleaving (validation errors were already request-fatal).

Why N=4: bounded well below the pool ceiling so one multi-filter request can't monopolise Postgres connections; a guard test pins the range so raising it forces a bench re-run.

Verification

• cargo test -p buzz-relay: 453 passed, 0 failed (whole package, not scoped).
• New filter_query_pipeline_preserves_filter_order: proves ordered yield when the first filter is the slowest (the case where buffer_unordered would break dedupe order).
• New filter_query_concurrency_is_bounded guard.
• cargo fmt + clippy clean; pre-commit/pre-push hook suites green.

Not in this PR (deliberate)

The dedicated DISTINCT ON (channel_id) last-message query for get_channels step 5 — separate follow-up diff so each change carries its own correctness argument. S2 helps every multi-filter query; DISTINCT ON kills the worst single call site.