argsort: the `is_sorted` early exit calls its comparator through a function pointer when `descending` is a runtime value

AI disclosure: found and drafted with the help of Claude Code

The early exit added in #197 selects the comparator with a runtime conditional (xss-common-argsort.h#L630-L632):

auto comp = descending ? Comparator<vectype, true>::STDSortComparator
                       : Comparator<vectype, false>::STDSortComparator;
if (std::is_sorted(arr, arr + arrsize, comp)) { return; }

comp is a function pointer. If descending is a compile-time constant at the call site (static header API, everything inlined) the compiler can see through it and inline the comparison into the is_sorted loop. If descending is a runtime value it cannot, and the scan makes an indirect call per element. For input that is already sorted the scan is the whole cost of the call, so this is directly visible.

I ran into this in numpy/numpy#32690, which started forwarding NumPy's runtime descending flag to x86simdsortStatic::argsort instead of relying on the default false. That slowed down ascending argsort of sorted input. np.argsort, n = 1M, gcc 14.2, AVX2 (i7-13650HX), minimum over alternating runs of the two builds:

A fix inside the library could be to select the scan instead of the comparator, so each is_sorted instantiation has a comparator known at compile time, e.g. (untested):

bool sorted = descending
        ? std::is_sorted(arr, arr + arrsize, [](const T &a, const T &b) {
              return Comparator<vectype, true>::STDSortComparator(a, b); })
        : std::is_sorted(arr, arr + arrsize, [](const T &a, const T &b) {
              return Comparator<vectype, false>::STDSortComparator(a, b); });
if (sorted) { return; }

or to make descending a template parameter of xss_argsort and branch in avx2_argsort / avx512_argsort, the way xss_qsort already does it.

Start at xss-common-argsort.h lines 630-632 and trace xss_argsort through avx2_argsort and avx512_argsort; compare the compile-time branching used by xss_qsort. Reproduce the sorted and reversed benchmarks described in the issue, then verify that runtime descending avoids an indirect comparator call without changing argsort results or the early-exit behavior.