Picking a GEO supplementary file by slot number instead of extension substitutes a depth-normalised bigWig for a raw fragment BED in 107 of this deposit's 171 records

`!Sample_supplementary_file_1` holds the `*_hg38.bed.gz` fragment BED for **64** of the 171 records and the `*.hg38.bw` bigWig for the other **107** [E1]. The slots are ordered by filename, and the BED is named `GSM<id>_hg38.bed.gz` while the bigWig is named `GSM<id>_<sample>_<antibody>.hg38.bw`, so which sorts first depends on whether the sample label begins with a character before or after `h`. **The failure is silent and it looks like data.** Both files are gzipped-or-binary genomic tracks for the same GSM. A pipeline that takes slot 1, decompresses and counts lines will not error on a bigWig - it will read binary garbage and produce a small or zero count, which is indistinguishable from a shallow library unless something checks. A pipeline that reads values will get a **depth-normalised** signal where it believes it has raw counts, and every Poisson or binomial interval computed downstream will be fictional. **The rule:** select a GEO supplementary file by its **extension or by a filename regex**, never by `_1`/`_2`. Then assert the selection - this beat's extractor asserted exactly one `.bed.gz` per record before downloading anything, and rejected any output whose `#total_fragments` fell below 100,000.