feat(search): query operators from: / in: / before: / after: (backend already supports them, client never sends them) #2853

Problem

Search accepts free text only. There is no way to narrow a query to a person,
a channel, or a date range. The from: / in: / before: / after:
operators are muscle memory for anyone coming from Slack, and a Slack-parity
gap in the sense of #2728. Today the only narrowing that exists is
programmatic: the in-channel find bar scopes by the current channel.

What already exists (the surprising part)

The entire backend path is already built. SearchQuery in
crates/buzz-search/src/query.rs carries authors, since, until, kinds
and a channel scope, and both relay search paths already map those fields
from the incoming NIP-01 filter:

• WS NIP-50 path: crates/buzz-relay/src/handlers/req.rs (~L599)
• bridge path: crates/buzz-relay/src/api/bridge.rs (~L1698)

So a filter like {"search": "deploy", "authors": [<pubkey>], "since": …, "until": …, "#h": [<channel>]} filters correctly on the relay today. The
existing per-hit re-authorization is untouched: the relay refetches and
re-authorizes every hit, so operators cannot widen visibility ("search is
never the access boundary").

What's missing is entirely client-side: the desktop sends only
{search, search_mode, limit, "#h"} (build_search_messages_filter in
desktop/src-tauri/src/commands/messages.rs), and nothing anywhere parses
operator syntax.

Proposed v1 scope

Client-only. No new event kinds, no relay changes, no schema changes.

Syntax (parsed out of the search input; remaining text is the FTS query):

Implementation sketch:

1. Pure-TS operator parser in desktop/src/features/search/lib/ (unit-tested;
   invalid operator text simply stays in the FTS query).
2. Autocomplete for from: / in: in the topbar search, reusing the existing
   user/channel pickers; active operators render as removable filter chips.
3. Extend the search_messages Tauri command with optional
   authors / since / until params and emit them in the filter, adding a
   few lines next to the existing build_search_messages_filter unit tests
   that pin the client/relay filter contract.
4. Typeahead: operators are stripped before the prefix-mode tsquery is built,
   so search_mode: "prefix" behavior is unchanged.

Explicitly out of scope for v1 (each needs backend work or product
decisions, happy to file follow-ups):

• has:link / has:image / file-type filters (needs an indexed signal for
  attachment presence)
• a dedicated file/attachment search surface
• natural-language dates (before:yesterday)
• group/thread scoping operators

Open questions for maintainers

1. Should operators live in the ⌘K topbar search (current mixed
   channel/user/message results), or is a dedicated search view planned that
   this should target instead?
2. Any preference on syntax? (from: vs author:; whether in: should also
   accept DMs.)
3. buzz-cli / agents already speak raw NIP-01 filters, so they get nothing
   new from this. If you'd like the same operator string parsed by
   buzz-cli search for symmetry, that could be a follow-up.

If the approach sounds right I'm happy to implement it, splitting it as
(1) parser + command plumbing and (2) autocomplete + chips UI if you prefer
two smaller PRs.