[FEA]: Add descending-order support to the LRB segmented-sort backend #12471

Area

CUB

Problem

The current LRB backend enables ascending keys-only sorting. Descending support requires consistent ordering in local sorting, padding, merging, and large-segment handling rather than changing only the final store order.

Proposed work

• Propagate sorting direction through dispatch, adapters, and workers using CUB's existing comparator/policy conventions.
• Make local sorting, incomplete-run padding, MergePath, and SerialMerge agree on descending order.
• Coordinate direction with the existing CUB overflow agent and future pair/DoubleBuffer paths.
• Enable supported existing descending test cases without silently falling back to the old backend.

Validation / completion criteria

• Cover negative, duplicate, finite floating-point, empty, partial, and capacity-boundary inputs.
• Verify stable descending pair behavior when key/value support is available and use the established API contract for special floating-point values.
• Benchmark ascending versus descending and check that direction selection adds no unnecessary runtime kernel launches.

Context

Follow-up to the LRB segmented-sort backend in #12236.

Related follow-ups

• [FEA]: Add key-value pair support to the LRB segmented-sort backend #12469
• [Enhancement]: Integrate k-way merge, SSB, and segmented-radix paths for LRB large segments #12468