fix(engine): prefilter(true) for filtered vector/FTS search

Lance's scanner defaults to prefilter=false: a filter riding the same
scanner as nearest()/bm25() is applied AFTER the ANN/FTS top-k, so
`limit k` meant top-k of the whole table and a selective predicate
silently starved results (the deny-list's silent-partial-result shape;
measured by the nearest-prefilter bench scenario: 20k rows, s=0.05,
k=10 -> 1000 matching rows exist, 0 returned). Set prefilter(true)
whenever a structured filter is pushed to the scanner: one flag governs
both the vector and FTS sources, plain scans ignore it, and it
re-enables scalar-index acceleration for the predicate under nearest.

The red test turns green: filtered nearest now returns the top-k of
MATCHING rows. Docs state the filters-before-search contract explicitly
(docs/user/search/index.md).

Closes iss-nearest-postfilter-starves-results.

docs/user/search/index.md

@@ -20,6 +20,10 @@ rank).
 - `nearest()` requires a `limit`. The query vector is resolved from the param map,
   or embedded from a text input at runtime via the configured
   [embedding client](embeddings.md).
+- Match filters apply **before** the search: combining a `match` predicate with
+  `nearest()` (or `bm25()`) returns the top-`limit` of the *matching* rows —
+  never a post-filtered remainder of the global top-k. A selective filter
+  narrows the candidate set; it cannot starve the result count.
 - Scores and ranks propagate as ordinary columns, so you can `return` a score and
   `order` by it.