Sparse parity-check matrix support for decoders

[vedika-saravanan]

Continuation of #440. Closes #379.

Introduces cudaq::qec::sparse_binary_matrix (CSC/CSR, uint32_t indices) as the decoder PCM type, so large PCMs no longer have to be materialized as a dense cudaqx::tensor. The sparse path is wired through PCM generation, round slicing, decoder construction, and Python bindings. sliding_window canonicalizes once and reads H.ptr() / H.indices() directly per window.

Breaking changes

• Decoder constructor now takes const sparse_binary_matrix &H. Dense cudaqx::tensor<uint8_t> callers still compile via implicit conversion, but the extension-point template changed — out-of-tree plugins must be recompiled.
• generate_random_pcm throws above k_max_dense_pcm_elements (400M). Use generate_random_pcm_sparse for larger matrices.
• single_error_lut_example now uses column qErr of H directly instead of XOR-of-other-columns (the old form was only correct when every row of H had even weight). Example plugin only; production single_error_lut was already correct.

Follow-up PRs

• Sparse-aware PCM utilities: migrate sort_pcm_columns, simplify_pcm, reorder_pcm_columns, shuffle_pcm_columns, pcm_extend_to_n_rounds, pcm_to_sparse_, pcm_from_sparse_, and detector_error_model::canonicalize_for_rounds to sparse_binary_matrix so the full cudaqx::tensor fails to allocate large PCMs #379 scale pipeline avoids any dense cudaqx::tensor<uint8_t> allocation.
• Docs: Sphinx entries for the new type/functions and the 400M dense cap.

Note to reviewers: Quick context on why it's larger than the ~1000-line guideline: it's a foundational type-system change rather than an additive feature. The new sparse_binary_matrix type, the decoder constructor breaking change, all the plugin updates, the sparse generator, and the Python bindings all have to land together for the #379 fix to actually be usable end-to-end. Splitting it would create intermediate states where the breaking change has landed but users still can't construct a >50k-mechanism PCM which would mean shipping the API churn without the benefit.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[vedika-saravanan]

Thanks, Vedika. I think these changes are looking pretty good. Could you please prepare any necessary changes to the nv-qldpc-decoder (closed source) before we merge this?

@bmhowe23, I have raised a merge request for necessary changes in nv-qldpc-decoder (219)

[bmhowe23]

Thanks, @vedika-saravanan.