Support QQQ (.lcd TLM Raw Data) variant - misdetected as QTOF, not decoded

[Nathan-D-R]

Summary

The corpus expansion in #3 added the first confirmed QQQ (triple quadrupole) sample: MTBLS12691, an LCMS-8060 system running MRM-targeted acquisition. These files currently fail to open in the reader.

Two separate problems

1. The QQQ on-disk variant is not decoded at all. Its real per-spectrum data lives under a TLM Raw Data storage (TLM Raw Data/MS Raw Data, TLM Raw Data/Spectrum Index, TLM Raw Data/Retention Time, plus status/TIC streams) - structurally closer to .qgd GC-MS's MS Raw Data/Spectrum Index naming than to either TTFL Raw Data (IT-TOF) or QTFL RawData (QTOF), which tracks with QQQ and GC-MS both being quadrupole-based rather than TOF-based. Nothing in crates/openszraw::raw reads this storage today.

2. raw::detect_variant actively misidentifies these files as QTOF. Every .lcd file - QQQ ones included - carries an always-present QTFL RawData storage as boilerplate, even when it has none of the substreams (Centroid Index, Centroid Data) that make a file actually QTOF. detect_variant checks TTFL Raw Data first, then treats any remaining QTFL RawData presence as sufficient to call it Variant::Qtfl - so a QQQ file with an empty QTFL RawData storage gets misclassified as QTOF, and then fails with stream 'QTFL RawData/Centroid Index' not found instead of a clear "QQQ/TLM not yet supported" message.

Confirmed by listing the full CFBF storage tree of MTBLS12691/20210325_024.lcd: QTFL RawData is present and empty; TLM Raw Data is present and populated with real per-scan data.

Suggested split

• Quick, low-risk fix: teach detect_variant to check for actual QTFL substreams (not just storage presence), or add an explicit Variant::Tlm/Unsupported case, so QQQ files fail with an honest "this is a QQQ/TLM file, not yet supported" message instead of a misleading QTOF stream-not-found error.
• Bigger, needs its own clean-room analysis: decode TLM Raw Data itself. MTBLS12691 now has 12 files fetched locally (of ~296 available across the study's five remote subdirectories - see CORPUS.md and analysis.external's MTBLS12691 entry in re/src/analysis/external.py for the rest).

See docs/format/06-known-limitations.md section 7 for full detail, and CORPUS.md's MTBLS12691 row.

[Nathan-D-R]

Corpus update from the 2026-07-24 cross-repo sweep: CORPUS.md now lists 5 QQQ accessions (MTBLS12691, MTBLS7425, MTBLS2376, MTBLS14423, MTBLS14566 - 275 files total) spanning at least 3 QQQ instrument generations (LCMS-8040/8060/8060NX), versus the single 12-file accession available when this issue was filed. Doesn't change the technical difficulty, but the 'not enough corpus to corroborate a decode' concern is much less true now - worth factoring in whenever someone picks this back up.