memory_pipeline re-spells the heavy phase: the #149 anti-drift fix covered only the selection half

[nikolay-e]

memory_pipeline::build_diff_context_in_memory lines 86-160 (75 lines, 48% of
the body) are a step-for-step parallel of pipeline.rs compute_scored_state
(:553-587) plus run_selection (:756-772): token counts,
identify_core_fragments, core excerpts, signature variants,
compute_seed_weights, score_and_filter, needs_from_diff — same operations,
same order, second spelling.

pipeline.rs:649-653 documents #149, where exactly this drift meant "the
harness measured a system nobody runs." The fix then introduced
select_and_postpass and closed the selection half. The heavy half was left
forked, so the same failure mode is still live in the same file that
memorialises it.

memory_pipeline.rs has one caller (test_harness.rs, the diffctx-test
example binary the YAML corpus drives), which is what makes the drift dangerous
rather than merely redundant: if it diverges, the corpus gate stops measuring
the shipped pipeline and nothing says so.

Fix: extract pipeline::score_from_fragments and have both paths call it.
Ship the −25 shared-prologue version first, the fuller −120 consolidation as a
second commit.

Naming note while in here: "memory" in memory_pipeline.rs means in-memory
input, not RAM — the RAM module is peak_rss.rs. in_memory_harness.rs would
stop that collision, but that rename is cheap only once the duplication is gone.

Gate: bitcheck (24 cells) + full corpus. The corpus is the meaningful one here,
since it is the consumer.

Protocol: ANALYSIS_code_cleanliness_refactoring.md §6 M1, R2.2 row 35.

[nikolay-e]

Partly done in ca8e7a6 (corpus 2902/2902, bitcheck 24/24).

Landed — the dangerous half. The token-count formula
count_tokens(&f.content) + LIMITS.overhead_per_fragment was written out five
times across the two files; it is now pipeline::assign_token_counts /
assign_excerpt_token_counts in one place, called from both. That is the piece
whose drift produces #149 exactly: if the harness and the shipped pipeline ever
disagree about what a fragment costs, the corpus measures a system nobody runs,
and nothing says so.

A guard difference nearly made this output-changing, so recording it.
assign_token_counts carries if frag.token_count == 0; the three inline loops
in memory_pipeline overwrote unconditionally. Substituting the guarded
helper is only equivalent if no fragment ever arrives with a non-zero count.
Checked every producer before touching it: fragmentation.rs:179,400,
signatures.rs:146, excerpt.rs:79,128, parsers/* all set token_count: 0;
the only non-zero literals (signatures.rs:165,332, both token_count: 100) are
inside mod tests at :155. So in production the guard is always true and the
substitution is bit-identical — which the corpus then confirmed.

Still open: lines 86-160 of build_diff_context_in_memory remain a
step-for-step parallel of compute_scored_state:553-587 + run_selection for
everything other than the token counts — identify_core_fragments, core
excerpts, signature variants, compute_seed_weights, score_and_filter,
needs_from_diff, in that order. Extracting pipeline::score_from_fragments is
still the fix.

Two real differences a future extraction has to carry as parameters, not erase:
the harness passes None for the repo root where production passes
Some(root_dir), and Deadline::none() where production passes its deadline
(the latter is deliberate and documented at the call site, #210).

The rename to in_memory_harness.rs stays deferred: worth doing once the
duplication is gone, not before.

[nikolay-e]

Linked to v3 prerequisites #245 item 5: the deletion-parity test must run both pipelines over the same deletion (today the git side is a hand-written literal). Do together with the shared prologue.