docs(SegmentTree): describe the baseline as a fold loop, not a Min() call

The baseline was written as `values.AsSpan(start, length).Min()` in the type
docs, the API reference and the benchmark header. Two things wrong with it.
It is min-specific, in the docs for a type whose whole point is an arbitrary
associative fold. And it does not compile: `Span<T>` has no `Min` — there is
no MemoryExtensions overload for it — so a reader who tried the snippet would
find out the hard way.

Reworded all three as what the baseline actually is: a hand-written loop that
folds the slice element by element, O(n) per query whatever the fold, against
which precomputing the answers instead trades the cost onto every point
update. The absence of a span helper is now stated rather than assumed, and
range minimum is named as the instance the benchmark measures — it is the
cheapest fold that loop can carry, so it is the baseline's best case.

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

Author: marius-bughiu

docs/api/collections.md

@@ -4279,7 +4279,7 @@ A **segment tree** is a fixed-length, array-backed sequence that answers the agg
 
 It is the half of the range-query space [`FenwickTree<T>`](#fenwicktreet) cannot reach. A Fenwick range query is the *difference* of two prefix folds, so the operation must have an inverse — which is why that type is constrained to `INumber<T>` and answers sums only. A segment tree stores each node's fold outright and never subtracts, so range **minimum**, **maximum**, **gcd**, bitwise **and**/**or** — and any fold you write yourself — are all in reach. Where sums are what you want, prefer `FenwickTree<T>`: it does the same job in half the memory.
 
-The BCL has no range-aggregate structure at all, so the baseline is a plain `T[]` and a scan — `values.AsSpan(start, length).Min()` is `O(n)` per query, and precomputing the answers is `O(n)` per update.
+The BCL has no range-aggregate structure at all, so the baseline is a plain `T[]` and a loop that folds the slice element by element — `O(n)` per query, whatever the fold — while precomputing the answers instead makes every point update `O(n)`. There is not even a span helper to lean on: `Span<T>` has no `Min` or `Max`, let alone an arbitrary combine, so the loop is written out by hand. (The benchmark measures the range-**minimum** instance of it, which is the cheapest per element the baseline gets.)
 
 ### The fold: `IMonoid<T>`
 

src/Celerity.Benchmarks/SegmentTreeBenchmark.cs

@@ -4,8 +4,10 @@
 
 // SegmentTree<long, MinMonoid<long>> vs the plain-array baseline, on the fold FenwickTree structurally cannot
 // answer. A Fenwick range query is the difference of two prefix folds, so it needs an inverse; minimum has
-// none. The BCL ships no range-aggregate structure at all, so the honest baseline is a raw long[] and a scan:
-// values.AsSpan(start, length).Min() is O(n) per query, and precomputing the answers is O(n) per update.
+// none. The BCL ships no range-aggregate structure at all — not even a Span<T>.Min to lean on — so the honest
+// baseline is a raw long[] and a hand-written loop folding the slice: O(n) per query, while precomputing the
+// answers instead would make every point update O(n). Range minimum is the cheapest fold that loop can carry,
+// which makes it the baseline's best case and the fair one to measure against.
 //
 // Two categories cover the documented BCL-beating shape. Mixed interleaves point updates with range-minimum
 // queries (the headline workload: sliding-window minima over a mutating history, "cheapest offer in this

src/Celerity/Collections/SegmentTree.cs

@@ -22,9 +22,11 @@ namespace Celerity.Collections;
 /// prefer <see cref="FenwickTree{T}"/> — it does the same job in half the memory.
 /// </para>
 /// <para>
-/// The BCL has no range-aggregate structure at all, so the baseline is a plain <c>T[]</c> and a scan:
-/// <c>values.AsSpan(start, length).Min()</c> is <c>O(n)</c> per query, and precomputing the answers is
-/// <c>O(n)</c> per update. The tree gives <b>both</b> in <c>O(log n)</c>, so it wins precisely when updates and
+/// The BCL has no range-aggregate structure at all, so the baseline is a plain <c>T[]</c> and a loop that folds
+/// the slice element by element — <c>O(n)</c> per query, whatever the fold — while precomputing the answers
+/// instead makes every point update <c>O(n)</c>. There is not even a span helper to lean on: <c>Span&lt;T&gt;</c>
+/// has no <c>Min</c> or <c>Max</c>, let alone an arbitrary combine, so the loop is written out by hand.
+/// The tree gives <b>both</b> in <c>O(log n)</c>, so it wins precisely when updates and
 /// range queries interleave — sliding-window minima and maxima over a mutating history, per-window
 /// capability masks, "cheapest offer in this price band" over a live order book, and the same rank / windowed
 /// aggregate shapes <see cref="FenwickTree{T}"/> serves for sums.