fix(search)!: reject a date range bound the codec cannot read, instead of dropping it

[ddeboer]

A date range bound isoToUnixSeconds cannot read was dropped, and a criterion left with no
usable bound compiled to VACUOUS – “states no constraint”, true for every document. So a
filtered search silently answered with everything, and under an or clause the vacuous
reading short-circuited the whole clause, deleting the valid criteria beside it. Nothing in the
response distinguished any of that from a deliberate match-all.

Rejected at the edge, not compiled

validateQuery gains an unparseable-bound issue, reported per rejected bound – the first rule
about a criterion’s value rather than its field, because no surface’s type system catches it
(String is String). assertValidQuery therefore throws for every caller: GraphQL, deployment
queryDefaults, in-process callers alike.

QueryIssue carries a new optional value naming the literal that was rejected, so a caller is
told which bound to fix and not just which field. assertValidQuery renders it:
where: “datePosted” (unparseable-bound: “yesterday”).

Not deep-time-specific: 'yesterday' behaved identically, and has since before the codec expanded
out-of-form years (#741, #747).

Why the compiler is left alone

The issue also proposed compiling an unreadable bound to UNUSABLE rather than VACUOUS. I tried
that and measured it, and it does not hold up: UNUSABLE reads as false within a clause (it
drops out of the ||, siblings stand) but the moment it empties a clause, compileFilterBy omits
that clause from the && – and an omitted conjunct is true. So status is valid AND date is garbage compiled to status:[valid], dropping the date constraint and returning more than
was asked for. It fixed the OR-sibling case and regressed the commoner AND cases.

The underlying reason is that filter_by has no term meaning “matches nothing”, so neither
reading can be right in both positions. The compiler keeps its existing behaviour and its JSDoc
now states this limit plainly, pointing at validation as the fix.

That leaves a real but separate defect: any clause left with no terms silently widens the
query, including one whose only criterion names a misspelled field. isUnsatisfiable covers only
the empty-id shape. Filed separately – it is not a date bug.

Also fixed

A null range bound (a GraphQL variable left unfilled, which the surface passes through) compiled
to datePosted:[null..…], which Typesense rejects – an unset filter failing the whole search. It
now reads as a bound not set.

Fix #750