Measure and reduce peak memory across raw loading, libraries, and search results

[jspaezp]

Problem

Search memory can grow with the size of the raw data and spectral library, with no explicit peak-memory budget. Large runs may compress or swap memory and slow down for reasons unrelated to a code change. Runtime process metrics are tracked in #150; this issue tracks reducing the peaks they reveal.

Three places to inspect

1. Raw-data loading. timsseek_cli::search::process_file calls load_index. The raw .d path currently materializes an eager index; index_serde.rs says raw files require eager loading. Measure peak memory while centroiding/indexing and while the index remains alive during search. Check whether temporary raw buffers overlap the completed index and whether a cached/lazy index can help.
2. Spectral-library loading. speclib_from_uri constructs a ReferenceLibrary that remains alive across files. Measure peak memory during parsing/building and steady-state bytes per entry. Check temporary copies, optional calibration-library duplication, and whether the representation can be more compact or loaded in parts.
3. Intermediate search results. phase3_score extends one Vec<ScoredCandidate> with results from every batch. Competition and rescoring then take whole-result vectors. Measure retained bytes per candidate and overlapping vectors/feature matrices; investigate earlier compaction, in-place reuse, bounded batches, or disk-backed intermediates where semantics permit. The raw-score path already writes batches directly to Parquet.

Some global operations may require whole-run information. Document those constraints rather than assuming all stages can stream.

Acceptance criteria

• Profile representative large inputs and record peak resident memory by stage, plus growth against raw-data size, library entries, and candidate count.
• Identify the largest retained structures and temporary overlaps in all three places above.
• Reduce the worst avoidable peak, with before/after measurements on the same workload and equivalent search outputs.
• Document any remaining whole-run stage's expected memory scaling and practical limits.