fix(search-typesense)!: compile a where clause that can match nothing to a term matching nothing

[ddeboer]

A where clause whose every criterion compiles to nothing was left out of filter_by – and a
conjunct missing from a conjunction constrains nothing. So a clause the compiler read as false
was emitted as true: one misspelled field name turned a filtered search into the whole
collection.

where: [
  { or: [{ field: 'status', in: ['valid'] }] },
  { or: [{ field: 'nonexistent', in: ['x'] }] },
]
// filter_by: "status:[`valid`]"   ← the false conjunct is simply gone

The term for “nothing”

A clause with criteria but no terms now compiles to id:=[] – an empty identity membership,
“the document is one of no documents”. Not a sentinel: it is the same reading isUnsatisfiable
gives an empty id membership in the IR, and the one shape a filter language can spell when it
has no keyword for false.

It had to be a term the engine applies rather than ignores, so I checked the candidates against
a real Typesense 30.2 instance: id:=``` is rejected outright (“Filter value cannot be empty”), while id:=[]returns 0 against a baseline of 2. A new integration test insearch-engine.test.ts`
pins that down – the fix is worthless if the engine ever starts ignoring the term.

A clause carrying no criteria at all ({ or: [] }) states nothing rather than stating false,
so it stays the vacuous no-op it reads as. That distinction is now the one thing compileFilter
decides, and its JSDoc says so.

onIgnoredFilter keeps firing for both kinds, since neither compiled as the caller wrote it –
its doc now describes the two cases instead of implying every reported clause was skipped.

Reachability

Not reachable through search(): assertValidQuery rejects an unknown field, a non-filterable
one and an operator mismatch before compiling, and isUnsatisfiable answers the empty id
membership without a round-trip. The exposure was, and the fix is for, direct callers of the
exported buildSearchParams.

Fix #752