fix(core): fill a filtered vector window instead of stopping at rejected neighbours

[phernandez]

Summary

Seventh PR in the #1558 stack, on top of #1569. Second half of the "vector order" item: a vector or hybrid search that carries structured filters now fills its candidate window.

What was wrong. The vector index ranks by similarity alone and cannot evaluate note types, dates, categories, metadata, path prefixes, or valid time. Retrieval took one window of candidate_limit chunks from that ranking and asked the full-text pass which of them the filters admitted. When the nearest chunks belonged to rows the filter rejects, the window held few admitted rows while more sat just past it, and the page came back short although matches existed. Twelve archive notes nearer the query than three matching notes were enough to turn a file_path_prefix="notes" search into an empty answer.

What changes. vector_only resolves its window through a small loop: read the window, resolve chunks to rows (keys, threshold, row fetch, filter), and if the query has filters and the window is not full, read it again twice as wide. The loop stops when the window holds candidate_limit admitted rows, when the ranking is exhausted (a short read, no growth between reads, or the existing 50k scan cap), or when the tail of the ranking has fallen below the similarity threshold, past which nothing further can qualify. A query without filters reads its window once, exactly as before.

This is the same rule for both routes and every adapter, and it adapts to filter selectivity without estimating it: a broad filter finishes in one read, a narrow one pays a few more reads of the same ranking. It replaces neither the scope pre-filter from #1569 nor the candidate-key restriction from #1431; it sits on top of both.

Shape. The chunk-to-row resolution that used to sit inline in vector_only moves into _resolve_rows, returning a frozen CandidateWindow. _run_vector_query, hydration, and the trace stage are unchanged; each round replaces the previous round's rejection lists, so a trace reads the final window.

Test plan

• just fast-check
• New tests/repository/test_vector_filter_window.py: the window widens 20 then 40 and returns the admitted rows; an unfiltered query reads once and never asks the filter; an exhausted ranking returns what it admitted; a ranking that stops growing ends the loop; a sub-threshold tail ends it; the widening is bounded by the scan cap; each round asks the filter only about the candidates it holds. Five of the seven fail on the previous reader.
• New repository test through the real sqlite-vec adapter and manifest: twelve nearer rejected rows in front of three admitted ones, window of ten, page of one; previously empty.
• Reader, trace, rerank, pagination, temporal, path-prefix, and candidate-restriction suites (202 passed)
• tests/repository tests/services tests/api plus the search tool tests on SQLite (2193 passed)
• Postgres container: repository, candidate restriction, trace, window, reader, vector sync, scoped route, semantic service (151 passed)
• test-int semantic coverage, search diagnostics, vec0 status (13 passed)

Refs #1558

🤖 Generated with Claude Code

https://claude.ai/code/session_019YW9ysxugGGBCNEGzsxtFV

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.