Recall-stage rerank-stage search pipeline

[luciaquirke]

Grosse et. al recommends a search pipeline-style setup where the more expensive method only reranks the top-k queries according to a cheaper and/or recall-optimized method that overfetches.

• Add score_cfg.candidates on score for the overfetched candidates. ekfac and trackstar pull from this. Two steps in one YAML can compose the stages.
• Candidates are the union over the earlier run's query columns of each column's top_k or fraction rows at the direction end (proponents / detractors).

TODO claude slop

• The store keeps every row. Candidates carry the new scores; the rest keep the earlier run's, negated if the runs disagree on higher_is_better, scaled to the candidates' spread and shifted past the weakest candidate, so validate, recall and load_scores see one complete ranking. candidates.npy lists the rescored rows.
• MemmapSequenceScoreWriter gains rows, mapping subset indices onto store rows.
• Per-token stores are rejected. The earlier run must have the same number of score columns, or one.

Examples: examples/pipelines/projected_kfac_then_shampoo.yaml, examples/pipelines/trackstar_then_shampoo.yaml. Docs: docs/influence-functions.rst.