feat: add GPU support to ribodetector (dual-container)

[pinin4fjords]

Summary

• Add GPU container switching to ribodetector: when task.accelerator is set, uses a CUDA-enabled container with pytorch-gpu; otherwise uses the existing CPU container
• CPU users are unaffected (same ~546 MB container), GPU users get a ~3.5 GB container with CUDA
• Both conda and container directives use ternaries based on task.accelerator
• Fix a latent GString interpolation bug in the memory flag ($task.memory.toGiga() -> ${task.memory.toGiga()})
• Fix stub gzip syntax for nf-core lint compliance
• Add GPU-tagged tests (real + stub) following the parabricks test pattern
• Improve both CPU and GPU tests: use nft-fastq plugin for order-independent sorted read name comparison, log content assertions for classification counts (4159 non-rRNA, 0 rRNA), ANSI color stripping

Container size

The GPU container is ~3.5 GB vs ~546 MB for the CPU container. The size comes from pytorch-gpu bundling the CUDA toolkit, cuDNN, and GPU-specific pytorch builds. With the dual-container approach, CPU-only users are unaffected.

GPU environment

The environment.gpu.yml uses conda-forge::pytorch-gpu=1.11.0. The CPU environment.yml is unchanged.

ARM limitation

The GPU container is x86_64 only. This is a conda packaging limitation, not a hardware one (ARM + NVIDIA GPU setups like Jetson do exist):

• All conda-forge ARM pytorch-gpu builds (oldest available is 2.1.2) depend on the __cuda virtual package, which requires CUDA drivers to be present at conda solve time. Wave's micromamba base image does not provide this, so the solve fails.
• The x86 pytorch-gpu=1.11.0 works because it predates the __cuda convention. It depends on cudatoolkit instead, which is a regular installable package that gets bundled into the container.
• Newer x86 builds (2.5.1+) also require __cuda and would fail the same way. The version pin to 1.11.0 is not just for reproducibility - it's the newest x86 version that avoids the __cuda gate.
• The pytorch channel packages avoid __cuda entirely (they use pytorch-cuda and pytorch-mutex real packages instead), but the pytorch channel has no ARM builds at all.
• We tested CONDA_OVERRIDE_CUDA=12.4 (which tells conda to pretend CUDA is present) but Wave does not support injecting environment variables at solve time, only at container runtime (--config-env).

Pipelines using this module should guard GPU ribodetector on ARM, as nf-core/rnaseq does:

if (params.use_gpu_ribodetector && (params.arm ?: false)) {
    error("--use_gpu_ribodetector is not supported on ARM architecture.")
}

Resolution paths:

1. Wave adds support for CONDA_OVERRIDE_CUDA at build/solve time
2. Wave provides CUDA-aware base images
3. conda-forge drops the __cuda requirement for ARM pytorch-gpu (unlikely, it serves a purpose)

Rationale

The ribodetector module already selects between GPU (ribodetector) and CPU (ribodetector_cpu) binaries based on task.accelerator, but the existing container only includes CPU pytorch, making the GPU binary fail with "CUDA unavailable". This PR adds the missing GPU container and wires up the selection.

Related pipeline PR: nf-core/rnaseq#1790

Test plan

• CPU tests pass (conda + docker, verified locally and in CI)
• nf-core lint passes
• GPU stub tests pass (docker + singularity)
• GPU real tests run ribodetector on NVIDIA GPU hardware with correct classification counts
• GPU and CPU produce identical classification results (same read counts: 4159 non-rRNA, 0 rRNA)

🤖 Generated with Claude Code

[pinin4fjords]

Thanks @jfy133 !