fix(retrieval): rerank scores the full block body, not the 200-char snippet

[jrosskopf]

Summary

The escurel-eval SciFact baseline (#235) showed the cross-encoder rerank stage (#215) regressing retrieval quality — nDCG@10 0.846 → 0.671 — instead of improving it. Root cause: Indexer::rerank_hits built the reranker candidates from SearchHit.snippet, the hydrated 200-char lead, so on abstract-length passages the cross-encoder judged relevance from ~13% of the text and reordered worse than the bi-encoder that embedded the whole doc.

rerank_hits now feeds the full block body: a new rerank_passages helper bulk-fetches blocks.body for the candidate set in one block_id IN (…) query and uses that as the passage text, falling back to the snippet for hits with no resolvable block (the sql_view lane). The reranker's own tokenizer truncates to its max length, so per-pair cost stays bounded.

Test plan

• cargo test -p escurel-index --test rerank
  • rerank_scores_full_body_not_just_the_snippet (new) — a note whose distinguishing token sits past the 200-char snippet is promoted by a keyword reranker only because the full body is now fed; it also asserts the token is absent from the snippet, guarding the premise.
  • existing reorder + set-preservation (INV-ACL-FUSION) and identity-when-disabled tests unchanged and green.
• Full local gate: fmt, clippy --workspace --all-targets -D warnings, cargo test --workspace --all-targets, cargo build --workspace --release.

Follow-up

Re-measuring the SciFact baseline with full-passage rerank is a separate, slow run (CPU cross-encoder throughput). The harness verifies the mechanism here; the empirical nDCG re-measure + a possible lower default rerank_candidates for latency come next.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}