Remove fixed UMI-tools seeds and fix UMICollapse jar discovery

[pinin4fjords]

Summary

• stop injecting --random-seed=100 in umitools/dedup and umitools/group
• stop setting PYTHONHASHSEED=0 in production commands
• keep module and dependent subworkflow tests deterministic through test configuration
• locate the UMICollapse JAR independently of the Conda package build suffix
• propagate UMICollapse Java failures through the logging pipe
• align three dependent samtools stats snapshot hashes with current output

Rationale

UMI-tools chooses a representative read randomly when duplicate candidates tie. Hard-coding a production seed makes that arbitrary choice repeat without making it robust, and prevents fresh runs from exposing stochastic variability. Users can still request reproducibility by setting --random-seed through task.ext.args.

UMICollapse is packaged with different build suffixes in the existing container and current Bioconda environment. Discovering its JAR within the active installation prefix supports both without pinning the wrapper to a particular package build.

Tests

• x86_64 Docker: all 13 affected UMI-tools module and subworkflow nf-tests passed
• x86_64 Docker: all 9 UMICollapse-dependent module and subworkflow nf-tests passed
• current Bioconda umicollapse=1.1.0 build: JAR discovery and BAM generation passed
• targeted pre-commit hooks and ruff format --check passed
• nf-core modules lint umitools/dedup: 61 passed, 3 existing metadata/container warnings
• nf-core modules lint umitools/group: 57 passed, 3 existing metadata/container warnings
• nf-core modules lint umicollapse: 60 passed, 1 existing process-label warning
• nf-core subworkflows lint bam_dedup_stats_samtools_umitools: 32 passed
• nf-core subworkflows lint bam_dedup_stats_samtools_umicollapse: 31 passed
• nf-core subworkflows lint bam_dedup_umi: 33 passed

[SPPearce]

No, I disagree entirely, I think we should be hardcoding random seeds if not specified.

[pinin4fjords]

No, I disagree entirely, I think we should be hardcoding random seeds if not specified.

This confuses me. If a tool doesn't set a random seed by default, why should we? The variant you force by setting the seed isn't any more valid than a variant you'd get by setting another one.

[maxulysse]

don't we have that in pipelines' nextflow.config already?