Support Stim DEM strings in get_decoder

[vedika-saravanan]

Description

Adds unified decoder initialization from either a parity-check matrix or raw Stim detector error model text.

This supports both existing PCM-based decoders and DEM-native decoders needed by #546. PCM-based decoders can parse DEM text into H, O, and error_rate_vec defaults, while DEM-native decoders can consume the raw DEM text without going through a lossy matrix conversion.

API (cudaq/qec/decoder.h)

• Adds decoder_init = std::variant<sparse_binary_matrix, std::string> as the decoder registry construction input.
• Keeps existing PCM construction paths:
  • get_decoder(name, H, options)
  • decoder::get(name, H, options)
• Adds DEM string construction through the same entry points:
  • get_decoder(name, dem_text, options)
  • decoder::get(name, dem_text, options)
• Adds dem_from_stim_text(dem_text) to parse Stim DEM text into detector_error_model.
• Adds helper routing for PCM-based decoders so DEM-derived O and error_rate_vec are supplied as defaults when not explicitly provided by the user.

The DEM-to-detector_error_model parser is lossy: it extracts detector flips, observable flips, and per-error probabilities, but drops detector coordinates and separator-encoded correlation structure. DEM-native decoders should consume the raw string alternative in decoder_init.

Python: cudaq_qec.get_decoder(...) now accepts Stim DEM strings. Python-registered decoders currently receive parsed H plus DEM-derived O / error_rate_vec defaults, not raw DEM text.

Dependency / build

QEC now provides its own Stim dependency via FetchContent when libstim is not already available, so standalone QEC builds do not depend on parent CUDA-Q interim build artifacts.

Tests

C++ gtests and Python tests cover:

• DEM string construction through get_decoder(...)
• PCM construction still working
• user-provided options overriding DEM-derived defaults
• DEM parse edge cases
• DEMs without observables
• stim::DemTarget category assumptions

Out of scope / follow-ups

Chromobius plugin integration itself; detector-coordinate storage on detector_error_model; optional PyMatching-specific improvements; user-facing Sphinx/RST docs.

Runtime / performance impact

N/A

Self-review checklist

Please confirm each item before requesting review. Check [x] or strike
through and explain.

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).
• 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.
• Tests fail if the new functionality is broken (including crashes), not
  just when it is missing.
• Negative tests added where exceptions are expected.
• Truth data added where simple EXPECT_* / assert checks are
  insufficient for algorithmic correctness.
• CI runtime impact considered; team notified if significant.

Documentation

• Public-facing APIs have Doxygen docs.
• User-visible behavior changes have public docs, or a follow-up is
  tracked.
• User-facing docs for new features are in a separate PR held until
  release (the docs site publishes immediately on merge to the default
  branch, so feature docs must not land before the feature ships).

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.

[bmhowe23]

This is looking good...thanks, @vedika-saravanan. Just a few follow-up questions below.

[bmhowe23]

I downloaded this PR and built locally (using 92d3dc9), and I see the following, which could be problematic:

$ nm -D lib/libcudaq-qec.so | grep stim | c++filt
00000000000907d0 W stim::DetectorErrorModel::~DetectorErrorModel()
00000000000907d0 W stim::DetectorErrorModel::~DetectorErrorModel()

The above two items are the only problematic items, so it's possible that your solution here covers most of the issue, but I don't think we should be leaking those symbol out.

In order to prevent something like NVIDIA/cuda-quantum#3045, I think something like NVIDIA/cuda-quantum#3076 is required.

[bmhowe23]

Just checking - does constructing a decoder w/o heterogenous map no longer supported? I don't think this is very common, so it's probably ok if we deprecate it; I just wanted to double check because if it still works then I'd want to keep this test.