test(rtpred): tolerate float32 batch-vs-single drift in Chronologer

The batched PredictRetentionTimeEquivalents override runs the model at
batch size m, while PredictRetentionTimeEquivalent runs it at batch size
1. libtorch selects different conv/matmul kernels for the two paths, so
predictions agree only to float32 precision (~1e-7 relative), not
bit-exactly. Two assertions used Is.EqualTo with no tolerance and failed
on that drift. Add .Within(1e-4) - orders of magnitude above the noise
floor yet tight enough to still catch a genuine batch/single mismatch.
Also soften the override docstring, which claimed the two paths give
identical results.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: trishorts

mzLib/Chromatography/RetentionTimePrediction/Chronologer/ChronologerRetentionTimePredictor.cs

@@ -86,7 +86,8 @@ protected override bool ValidateBasicConstraints(IRetentionPredictable peptide,
     /// Batched override: formats/encodes the peptides in parallel (CPU) and runs the Chronologer model in
     /// large batched forward passes instead of one locked batch-1 call per peptide. The model is in eval
     /// mode (BatchNorm uses running statistics), so each peptide's prediction is independent of the batch —
-    /// results are identical to <see cref="PredictCore"/>, just far faster for many peptides.
+    /// results match <see cref="PredictCore"/> to float32 precision (libtorch selects different conv/matmul
+    /// kernels at batch size m vs 1, so the two paths are not bit-identical), just far faster for many peptides.
     /// </summary>
     public override IReadOnlyList<(double? PredictedValue, IRetentionPredictable Peptide, RetentionTimeFailureReason? FailureReason)>
         PredictRetentionTimeEquivalents(IEnumerable<IRetentionPredictable> peptides, int maxThreads = 1)