fix(validate): fix trans_fetch_reads_limit, logging f-string, and chr…

[monicarojasp]

Description:
Summary
This PR fixes three bugs in the validate step that together caused transcriptome structural variant events requiring contig-based calling to silently fail validation. The bugs were identified while investigating why a SNX9-ARID1B duplication event (chr6:156829227-157875176) passed validation in MAVIS 2.2.6 but failed in MAVIS 3.1.0 and 3.1.2.

Bug 1 validate/gather.py: trans_fetch_reads_limit ignored for transcriptome libraries
When evidence gathering was refactored from a method on the Evidence object into the standalone gather.py module, all four fetch_from_bins calls started reading the fetch limit directly from the config dictionary instead of using the evidence object's property:

# Wrong always returns 3,000 for all libraries
read_limit=evidence_bpp.config['validate.fetch_reads_limit'],

# Fix returns 12,000 for transcriptome, 3,000 for genome
read_limit=evidence_bpp.fetch_reads_limit,

Impact: Transcriptome libraries use only 3,000 reads instead of 12,000. With large transcript-aware outer windows (~305kb for this event), the read budget is exhausted before reaching split reads near the breakpoint. This starves the assembler and produces 0 contigs, causing the event to fail.

Bug 2 validate/main.py: missing f-string prefix hides real error messages
A missing f prefix causes all validation error messages to print the literal string {repr(err)} instead of the actual exception:

# Wrong prints literal {repr(err)}
logger.warning('error in calling events {repr(err)}')

# Fix
logger.warning(f'error in calling events {repr(err)}')
Impact: Does not cause validation failures directly but makes debugging extremely difficult by hiding the real error message.

Bug 3 validate/align.py: chromosome name mismatch in select_contig_alignments
In MAVIS 2.2.6, blat.py stripped the chr prefix from chromosome names returned by BLAT (chr6 → 6). This stripping was removed in 3.1.0, so BLAT now returns chr6 while breakpoints are stored internally without the prefix as 6. The comparison in select_contig_alignments inside the for contig in evidence.contigs loop then fails:

# Wrong 'chr6' != '6' so every read is skipped
if (
raw_read.reference_name != evidence.break1.chr
and raw_read.reference_name != evidence.break2.chr
):
continue

# Fix normalize chr prefix before comparing
bp1_chr = re.sub('^chr', '', evidence.break1.chr)
bp2_chr = re.sub('^chr', '', evidence.break2.chr)

for contig in evidence.contigs:
...
for raw_read in reads_by_query.get(contig.seq, []):
raw_chr = re.sub('^chr', '', raw_read.reference_name)
if (
raw_chr != bp1_chr
and raw_chr != bp2_chr
):
continue

Impact: All BLAT contig alignments are silently discarded, giving 0 alignments to _call_by_contigs even when BLAT correctly aligned the contig to the reference.

Why only some events are affected
These bugs only surface for events that require a contig call specifically events with zero flanking pairs and insufficient linking split reads to be called by split reads alone. Most events are called via split reads or flanking pairs and never reach the code path affected by Bugs 1 and 3. Bug 2 affects all validation failures silently.

Test
Tested on a SNX9-ARID1B tandem duplication (chr6:156829227-157875176, ~1.05 Mb) in a transcriptome library aligned to hg38. Results before and after the fixes:

config.json parameters:
"validate.fetch_reads_limit": 3000,
"validate.trans_fetch_reads_limit": 12000

Metric Before (bug)
(fixed)fetch_reads_limit: 3,000
Split reads (BP1): 212
Split reads (BP2): 198
Assembly sequences: 362
Contigs assembled: 0
Contig alignments:0
Validation result: FAILED
Call method: —

Metric After (fixed)
fetch_reads_limit 12,000
Split reads (BP1): 938
Split reads (BP2): 1,464
Assembly sequences: 2,016
Contigs assembled: 1
Contig alignments: 2
Validation result: PASSED
Call method: contig

Files changed
src/mavis/validate/gather.py — Bug 1 fix (4 lines)
src/mavis/validate/main.py — Bug 2 fix (1 character)
src/mavis/validate/align.py — Bug 3 fix (6 lines)

[monicarojasp]

@creisle