feat: Add batch float32 zero-copy angle encoding in qdp-core

[viiccwen]

Related Issues

• Closes [Feature] Add batch float32 zero-copy angle encoding in qdp-core #1267

Changes

• Bug fix
• New feature
• Refactoring
• Documentation
• Test
• CI/CD pipeline
• Other

---

• add batched float32 CUDA kernel support for angle encoding
• expose the new kernel through qdp-kernels FFI
• implement host-side angle batch float32 encoding in qdp-core
• add zero-copy batch float32 angle APIs for CUDA pointers, including stream-aware variants
• align float32 GPU-pointer validation with the existing float64 angle batch behavior
• add kernel and core tests for success paths and failure paths

Why

QDP already had angle float32 zero-copy support for single samples, but not for batched angle features. That made batched angle workloads inconsistent with the existing single-sample API and with the amplitude float32 batch implementation pattern.

This change closes that gap in the Rust/CUDA core only. Python bindings remain out of scope for a follow-up PR.

How

• implement launch_angle_encode_batch_f32 in qdp-kernels/src/angle.cu
• add the corresponding extern declaration and non-CUDA stub in qdp-kernels/src/lib.rs
• extend AngleEncoder with host-side batch float32 encoding and batch GPU-pointer float32 encoding
• add public QdpEngine entry points for angle batch float32 zero-copy on the default stream and explicit streams
• validate sample shape and reject non-finite float32 GPU-resident batch inputs before launching the encoding kernel
• add tests covering kernel correctness, host-side batch encoding, zero-copy batch encoding, stream interop, error handling, and Float64-engine conversion

Checklist

• Added or updated unit tests for all changes
• Added or updated documentation for all changes

[rich7420]

@viiccwen thanks for the patch!
Could you add a NaN case to mirror the Infinity one, and also state_len == 0 /num_qubits == 0 launcher-rejection tests?

[rich7420]

nit: doc should mention that output precision follows the engine's configured precision, not necessarily f32 — F64 engine + F32 input yields complex128. Don't want downstream folks tripping on the DLPack dtype.