Add HLA-HD v1.7.1 module and BAM-input subworkflow

[johnoooh]

Add HLA-HD v1.7.1 module and BAM-input subworkflow

Summary

• Adds modules/msk/hlahd — nf-core-style module for HLA-HD v1.7.1 (high-resolution HLA typing from paired FASTQ)
• Adds subworkflows/msk/hlahd_from_bam — end-to-end BAM-to-HLA-typing workflow
• Adds test data entries to tests/config/test_data.config (data on hlahd branch of test-datasets repo)
• Adds docs/ci.md documenting the nf-test CI pipeline, written while debugging this PR's CI failure (see below)

Module: modules/msk/hlahd

Container	mskcc.jfrog.io/omicswf-docker-prod-local/mskcc-omics-workflows/hlahd:1.7.1
Input	[ meta, fastq_1, fastq_2 ]
Output	result (final allele calls), result_per_locus (per-gene .est.txt files), versions

• Min-read threshold configurable via ext.args2 (default: 100)
• Includes stub for pipeline dry-runs

Subworkflow: subworkflows/msk/hlahd_from_bam

Chains five modules to go from coordinate-sorted BAM to HLA allele calls:

[ meta, bam, bai ]
        |
  SAMTOOLS_VIEW         extract HLA region (configured via ext.args)
        |
  GATK4_REVERTSAM       optional BQSR reversion (skip_revert_sam param)
        |
  SAMTOOLS_COLLATE      name-collate reads (required before samtools fastq)
        |
  SAMTOOLS_FASTQ        BAM -> paired FASTQ
        |
  HLAHD                 HLA allele calling
        |
[ result, result_per_locus, versions ]

The skip_revert_sam parameter controls whether GATK4 RevertSam runs. Set to true when the input BAM has no BQSR applied.

SAMTOOLS_COLLATE runs unconditionally regardless of skip_revert_sam — see "CI fix" below for why.

Test data

Region	Coordinates (GRCh37)
HLA-A	6:29910247-29913661
HLA-B	6:31321649-31324989
HLA-C	6:31236526-31239913

~21k reads, ~3.3MB across 4 files (BAM + BAI + paired FASTQ).

Example output (test_sample_final.result.txt)

A       HLA-A*01:01:01  HLA-A*29:02:01
B       HLA-B*08:01:01  HLA-B*44:46
C       HLA-C*07:01:01  HLA-C*16:26
DRB1    Not typed       Not typed

Class II loci are "Not typed" as expected — only class I regions are included in the test data.

Tests

All 5 nf-test tests pass with deterministic snapshot matching:

Module tests (2):

• hlahd - fastq pair - result txt — real HLA-HD run, verifies final result md5
• hlahd - fastq pair - stub — stub run, verifies versions output

Subworkflow tests (3):

• hlahd_from_bam - bam - with revert sam - result — full pipeline with GATK4 RevertSam
• hlahd_from_bam - bam - skip revert sam - result — pipeline skipping RevertSam
• hlahd_from_bam - bam - stub — stub run

Both revert/skip-revert paths produce identical final calls.

CI fix: skip_revert_sam dropped ~99% of reads

CI was red on Test | docker | 4 / Test | singularity | 4 (the
skip revert sam test) for a while: SAMTOOLS_VIEW's coordinate-sorted BAM
output was fed straight into SAMTOOLS_FASTQ when skip_revert_sam = true.
samtools fastq needs name-grouped input to pair mates; on a
coordinate-sorted BAM it discarded ~99% of reads as singletons (verified: 8443/8501
discarded direct vs. 2183/8501 after samtools collate). That starved
HLA-A of coverage and it came back "Not typed" — the with_revert_sam path
only worked because GATK4_REVERTSAM defaults to a queryname sort, masking
the missing step.

Fix: added SAMTOOLS_COLLATE (nf-core module) unconditionally before
SAMTOOLS_FASTQ. Declared as a component dependency in
hlahd_from_bam's meta.yml, which CI fetches automatically via
.github/scripts/install-components.sh — see docs/ci.md
(added in this PR) for how that mechanism works. All 16 checks passed on
the first version of this fix.

Follow-up: components: schema didn't match the real nf-core CLI

While testing "does this subworkflow actually install into a pipeline"
(not just pass our own CI), nf-core subworkflows install hlahd_from_bam
against this branch crashed with AttributeError: 'str' object has no attribute 'get'. hlahd_from_bam's meta.yml was the first subworkflow
in the repo to declare an external (nf-core) components: dependency, and
the shape used (- name: ..., git_remote: ..., org_path: ...) only matched
what our own install-components.sh script parses — not what
nf-core subworkflows install itself expects
(components_utils.py::get_components_to_install, which wants the dict
nested under the component name: - samtools/collate: {git_remote: ...}).
So this passed CI fine but would have silently broken for the first
downstream pipeline to try installing it.

Fixed by switching meta.yml to nf-core's real nested shape and updating
install-components.sh to parse it the same way, so both consumers agree
on one schema. Re-verified both: install-components.sh still fetches all
4 dependencies locally, and nf-core subworkflows install hlahd_from_bam
now succeeds end-to-end in a scratch pipeline — installs the local hlahd
module plus all 4 transitive nf-core modules, correctly recorded in
modules.json. Documented in docs/ci.md.

Checklist

• Module follows nf-core conventions (meta map, ext.args, versions.yml)
• All 5 nf-test tests passing
• Snapshot files committed
• Test data on hlahd branch in test-datasets repo
• meta.yml complete for both module and subworkflow
• Container URL switched to prod registry

[price0416]

Looks solid, passes all tests.