pf_partial_sort and pf_partial_argsort -- ordering only the first n elements.
Same engine, same comparator, same tiers as a full sort (feature_risks.md Risk-34): these
reach std::partial_sort through the very object std::sort is given, so a partial result can
never disagree with the corresponding prefix of a full one.
n is clamped, not checked. Asking for more elements than the array holds returns all of
them, in order. That is deliberate -- n is very often derived, and refusing it would put
min(n, size(v)) at every call site. A negative n is a caller error and aborts.
A partial sort that is not actually partial is invisible: returning the first n of a FULL
sort is correct and merely slower, so no correctness test can tell the two apart. That is what
parquet_debug_get_sort_comparisons exists for, and why the guide states the complexity claim
with its own caveat rather than as a free win.