pf_minmax, pf_argminmax and pf_merge.
The extremes are two nth_element calls, not a hand-written scan. Rank 1 ascending is the
minimum and rank 1 DESCENDING is the maximum, so reaching them through the engine means the
answers cannot disagree with pf_sort's own ends (feature_risks.md Risk-34). Both calls are
O(n), the same as the scan would be, and neither needs a per-type comparison written here.
Rank n_value of the ascending order would name the same maximum VALUE, but the last of a tied
run rather than the first -- see minmax_impl_*'s own comment for why that asymmetry is not
acceptable in a pair of answers a caller reads together.
n_value counts rows that are neither null nor NaN. A NaN is skipped because it is not the
minimum or maximum of anything -- while staying an ordinary value everywhere else in this
module, which is exactly the asymmetry sort_tier_of already encodes.
pf_merge concatenates the two inputs into one key and merges the halves. The alternative,
comparing an element of a against an element of b through a second comparison path, is the
drift this module has spent three milestones avoiding.