Document sparse parity-check matrix support

[vedika-saravanan]

Description

Documents the sparse parity-check matrix support introduced across #550, #599, and #602.

This PR:

• Adds sparse_binary_matrix and sparse_binary_matrix_layout to the C++ API reference, including CSC/CSR storage, canonicalization semantics, and index limits.
• Adds the sparse PCM utility overloads and generate_random_pcm_sparse to the C++ API reference.
• Updates the C++ decoder extension examples to use sparse_binary_matrix, decoder_init, and make_pcm_decoder.
• Explains how make_pcm_decoder dispatches PCM and Stim DEM inputs.
• Corrects the single-error LUT example to consume canonical sparse columns directly.
• Documents SciPy sparse support and return types for the Python PCM utilities.

Related: #550, #599, #602.

Runtime / performance impact

N/A. Documentation-only change.

Self-review checklist

Before requesting review

• I reviewed my own full diff in GitHub or my editor.
• PR is in Draft if it is not yet ready for review.
• Temporary / debugging changes have been removed.
• Local test logs reviewed; no unexplained warnings or errors.
• CI logs reviewed; no unexplained warnings or errors.
• Full CI has been run.

Scope and size

• PR is under ~1000 lines, or an exception is justified in the description.
• Refactoring-only changes are isolated in their own PR(s).
  N/A: documentation-only change.
• No existing tests were disabled or modified just to make this PR pass
  (if so, an issue has been raised).

Tests

• New functionality has new tests.
  N/A: documentation-only change.
• Tests fail if the new functionality is broken (including crashes), not
  just when it is missing.
  N/A: documentation-only change.
• Negative tests added where exceptions are expected.
  N/A: documentation-only change.
• Truth data added where simple EXPECT_* / assert checks are
  insufficient for algorithmic correctness.
  N/A: documentation-only change.
• CI runtime impact considered; team notified if significant.
  No significant impact expected.

Documentation

• Public-facing APIs have Doxygen docs.
• User-visible behavior changes have public docs, or a follow-up is
  tracked.

Code style

• Naming follows the existing convention (snake_case vs camelCase) for
  the area being modified.

Dependencies

• No new third-party dependencies, or the team has been notified and
  OSRB tickets filed.