perf(passageRetrieval): rank without fts5 content columns; fetch labels per kept hit

The ranked query selected passage_search.citation and passage_search.name.
An fts5 column read materializes the WHOLE stored row - the passage text
plus its context header - so those two short strings cost ~1.6 KB per
candidate over a candidate pool of k*perDocCap*4. At the crowned config
that is 4,608 candidates against a 5,966-row index: essentially the entire
index body pulled through, to label the <=48 rows that survive the
perDocCap filter. Same class as 17884220: a large payload fetched
repeatedly for a small piece of it.

Labels now come from the same table, per surviving row, by rowid.
Identical strings from identical rows, so nothing about ranking or
selection moves.

Measured on the LegalBench mini bed (776 queries x crowned config, plus
five further configs on a private copy of the db to avoid contention):
  ranked query alone   50.4 -> 23.5 ms/query
  searchPassages       81.5 -> 32.5 ms/query (2.5x)
  6-config digest run  197.5s -> 74.5s (2.65x)

Unchanged-output proof: sha256 of every returned PassageHit array over
2,352 query-config cells - chars/clause modes, plain/phrases, contextWeight
0 and 2, four distinct sidecars, k in {4,8,48}, perDocCap in {2,24} - is
byte-identical before and after (digest of digests
07f50c02e7e111f9308c1c6da00718f298c564421c812753dbfc510d04716206). 76 tests
pass across passageRetrieval, a2ajPassageSearch, a2ajPassageWiring,
legalbenchRag, legalbench.

searchPassages is the product retriever, so this lands on the laptop-CPU
inference target, not just the harness.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9ToHYJVDxfeJcJwdzrP2H