Parse Typesense multi_search errors

[tlongwell-block]

Summary

• parse Typesense multi_search per-result {code, error} responses as SearchError::Api so schema/filter failures are diagnosable
• keep the HTTP /query bridge search contract unchanged: it still pushes channel_id filters into Typesense
• leaves the actual user-facing fix to schema repair/reindex of the stage events collection so the index matches the code's expected schema

Root cause

Stage's events Typesense collection appears to predate the channel_id facet field, even though the current Buzz search schema includes it:

{"name": "channel_id", "type": "string", "facet": true, "optional": true}

Typesense multi_search can return HTTP 200 with a per-result error like:

{ "code": 400, "error": "Could not find a filter field named `channel_id` in the schema." }

Before this PR, the search client tried to deserialize that per-result error as a normal search response, which hid the real Typesense error behind a JSON parse failure.

Fix direction

channel_id is part of the index/query contract, so this PR no longer works around missing channel_id by weakening bridge filtering. The better fix is to repair/recreate the stage events collection with the current schema and reindex it. See #1209.

Tests

• ./bin/cargo test -p buzz-search --lib query::
• pre-commit hook: rust fmt, desktop Tauri fmt, web/desktop biome + file-size checks, mobile format/analyze passed during amend
• pre-push hook: rust, desktop, mobile, and Tauri tests passed