Expose shrinking-radius traversal without standard-library dependencies

Motivation

Some CUDA consumers compile device code at runtime with NVRTC and do not provide the C or C++ standard library. Warp is one example: its JIT kernels compile with WP_NO_CRT.

Including cuBQL/traversal/shrinkingRadiusQuery.h currently pulls in cuBQL math, BVH, builder, and host-support headers. Those transitively include headers such as <math.h>, <iostream>, <string>, <stdexcept>, and <memory>. As a result, an NVRTC kernel cannot directly use
cuBQL::shrinkingRadiusQuery::forEachPrim() in this environment.

We would like Warp to call cuBQL's maintained traversal directly while passing a JIT-specialized Warp device function as the primitive callback.

Proposed direction

Extract the binary-BVH shrinking-radius traversal loop into a small, dependency-free header.

The low-level traversal would:

• Include no standard-library, cuBQL math, or builder headers.
• Accept the node and primitive arrays directly.
• Use small callbacks to access the encoded node administration data, calculate
  squared node distance, and process a primitive.
• Preserve the existing 48-bit offset / 16-bit primitive-count layout and
  64-entry traversal stack.
• Continue supporting CPU, CUDA, and HIP compilation.
• Leave the existing public shrinkingRadiusQuery::forEachPrim() signature
  unchanged by forwarding it through the extracted core.

This keeps one cuBQL-owned traversal implementation. Runtime-compiled consumers
only provide adapters for their compatible node and vector representations.

The exact header name and namespace are open for discussion. The prototype uses:

cuBQL/traversal/shrinkingRadiusQuery_device.h

and:

cuBQL::shrinkingRadiusQuery::device::forEachPrim()

Prototype validation

We tested the extracted traversal through both the normal cuBQL API and Warp's
WP_NO_CRT NVRTC path on an RTX A3000.

• Standalone CUDA/cuBQL: approximately 0.30–0.33 ms
• Warp calling the extracted cuBQL core: approximately 0.34 ms
• Candidates per query: 5.0001 in both implementations
• No meaningful distance differences
• CPU cuBQL build passed
• CUDA and NVRTC compilation passed

Would this device-core split be an acceptable direction for cuBQL?

Start by reviewing cuBQL/traversal/shrinkingRadiusQuery.h and the proposed cuBQL/traversal/shrinkingRadiusQuery_device.h prototype. Compare the existing public forEachPrim() path with the dependency-free traversal requirements, including the encoded layout and 64-entry stack. Done means CPU, CUDA, and NVRTC compilation pass while preserving the existing API and traversal results.