[CUB] Make negative size handling consistent among CUB primitives

Currently different CUB device primitives handle negative sizes (e.g. `num_items`, `num_segments`, `segment_size`) inconsistently. Some return an error like `num_segments` in `DeviceSegmentedScan` while others like `num_segments` in `DeviceSegmentedReduce` return success (clamp to non-negative -> 0 -> no work/trivial).

Before changing any interfaces we should be the decision on the right default. Many newer APIs like segmented TopK currently go the more lenient path of accepting/clamping negative sizes. While it is easier to change APIs in this direction (no need for a major version), the ultimate path is not decided yet.

There is an argument to be made that negative sizes signify a bug in preceding user code that could be hidden by clamping. On the other hand passing negative values and lazily clamping only when necessary can have performance advantages as sometimes the clamp can be completely avoided like in
```c++
if (idx < size) { ... }
```
This is especially true in device code. And handling this differently in device and host code is undesirable as well.

Start by comparing negative-size handling in DeviceSegmentedScan, DeviceSegmentedReduce, and newer segmented TopK APIs, including num_items, num_segments, and segment_size. First establish the project-wide default—error or clamping—then document the decision and identify the affected primitives and validation coverage needed for consistent behavior.

Written by the indexing model from the issue text.