Treat non-ppm precursor tolerance as 10 ppm default for MS1 envelope

[brendanx67]

Summary

run_coelution_calibration_scoring (both pass 1 and pass 2 in
pipeline.rs) was passing config.precursor_tolerance.tolerance
into the MS1 isotope-envelope extractor regardless of the unit. For
unit-resolution config (e.g. Stellar: tolerance=1.0, unit=Mz),
this was treating 1.0 Da as 1.0 ppm, producing a ~0.5 mDa
window at 500 m/z — effectively zero. envelope.has_m0() returned
false on ~99.8% of matches and only 18 of 7361 calibration-passing
entries contributed to ms1_calibration on Stellar Single, vs 193
on C# (10x undercount).

Fix

New helper ms1_envelope_tolerance_ppm in pipeline.rs:

fn ms1_envelope_tolerance_ppm(config: &OspreyConfig) -> f64 {
    match config.precursor_tolerance.unit {
        ToleranceUnit::Ppm => config.precursor_tolerance.tolerance,
        _ => 10.0,
    }
}

Wired into both pass-1 and pass-2 run_coelution_calibration_scoring
call sites. Mirrors the C# OspreySharp behavior in
PerFileScoringTask.ScoreCalibrationEntry (unit == Ppm ? tolerance : 10.0).

Cross-impl effect

On Stellar Single calibration.json, the
ms1_calibration.{count, mean, median, sd, adjusted_tolerance} drift
disappears from the cross-impl diff. It was the dominant
CAL_JSON divergence (diff 1.75e+2 at
ms1_calibration.count). Remaining cal_json drift is
rt_calibration.model_params.abs_residuals[i] sort-order swaps on
a handful of indices where the underlying values are bit-equal but
sorted slightly differently cross-impl (addressed in a sibling PR).

Production impact

For runs with ppm-unit precursor_tolerance (most HRAM workflows),
behavior is unchanged — the helper returns the configured value.

For runs with non-ppm precursor_tolerance (unit-resolution,
mass-window, etc.) the MS1 envelope tolerance now defaults to 10 ppm
instead of silently passing through the absolute value as if it
were ppm. This is the correct behavior — the envelope extractor
requires a ppm window — and matches the OspreySharp port.
Calibration counts will increase for these configurations
(typically by ~10×), which is the bug fix.

Detection

Found via OSPREY_DIAG_MS1 instrumentation showing tol_ppm=1.0
and peaks_in_m0_window=0 on all sampled calibration entries.

Testing

• cargo fmt --check
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test
• Cross-impl: Stellar Single calibration.json ms1_calibration
  block now matches C# OspreySharp; previously the dominant per-
  file calibration divergence.

[Copilot]

Pull request overview

Fixes MS1 isotope-envelope extraction in calibration scoring when precursor_tolerance is configured in non-ppm units (e.g., unit-resolution workflows). The pipeline previously passed the raw tolerance value as if it were ppm, effectively collapsing the MS1 envelope window and causing most envelopes to fail has_m0().

Changes:

• Added a ms1_envelope_tolerance_ppm helper that converts precursor tolerance to a ppm value usable by the MS1 envelope extractor (ppm passthrough; non-ppm defaults to 10 ppm).
• Updated both pass-1 and pass-2 run_coelution_calibration_scoring call sites to use the helper instead of config.precursor_tolerance.tolerance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.