Add NetCleave predictor for MHC-I/II C-terminal cleavage (#213)

[iskandr]

Closes #213.

Adds NetCleave, filling the MHC-II antigen-processing gap: NetChop and pepsickle only cover MHC-I proteasomal cleavage, and no class-II (endolysosomal) option existed in the predictor set.

What's new

Ontology

• Kind.endolysosomal_cleavage (MHC-II, cathepsin pathway) alongside the existing proteasome_cleavage (MHC-I, cytosolic). Naming follows the decision recorded on #213: name the machine when one dominates, the compartment when the machinery is a diffuse family.
• PeptideResult.endolysosomal_cleavage accessor.

Predictor

• NetCleave + NetCleave_I / NetCleave_II subclasses. Class I → proteasome_cleavage, class II → endolysosomal_cleavage.

from mhctools import NetCleave_II

p = NetCleave_II()                                  # resolves NETCLEAVE_DIR / ~/NetCleave
p.predict(["SIINFEKL"], c_flanks=["DGH"])[0].endolysosomal_cleavage.score
p.predict_proteins({"TP53": "MEEPQ..."}, peptide_lengths=[15])   # real protein context

Design: why not a ProcessingPredictor subclass

NetChop/pepsickle produce a per-position cleavage profile that the base class collapses to a per-peptide score. NetCleave instead emits one C-terminal score per peptide (the 4+3 cleavage site: last 4 residues of the peptide + 3 downstream). So it doesn't fit the cleavage_probs contract — it's a standalone subprocess predictor (NetChop-style: write a temp CSV, shell out to NetCleave.py --predict --pred_input 3, parse the output). Because the C-terminal site needs downstream residues, predict() requires c_flanks (≥3); predict_proteins() supplies real context automatically.

Distribution — no gated download, no R for prediction

• Weights ship in the git repo as small Keras .h5 files (~621 KB each), including the class-II models (II_mass-spectrometry_HLA-DR/DP/DQ). Just git clone.
• The R dependency in NetCleave's README is a red herring for prediction — iedb_processing.R is only used in training-data generation and is not referenced by any Python in the --predict path (verified). --predict needs only Python (tensorflow/keras, scikit-learn, biopython, pandas). The wrapper shells out to a user-provided interpreter (python_executable= to override), vendoring nothing (NetCleave is GPL-v2).
• The .h5 files are loaded as weights into an architecture NetCleave rebuilds in code, so loading is robust across Keras versions (verified on TF 2.21 / Keras 3.14).

Faithfulness — verified against upstream CLI

Tests reproduce NetCleave's own NetCleave.py --predict output exactly (abs=1e-3) on both the class-I and class-II pan models — reference values generated from the upstream CLI, not this wrapper (non-circular). A class-I > class-II signal check reflects the paper's AUC 0.91 vs 0.66.

⚠️ Class-II C-terminal cleavage is a genuinely weak signal (paper AUC ~0.66 vs ~0.91 for class I — the class-II C-terminus sits outside the binding groove and cathepsin specificity is diffuse). Documented in the class docstring, the README, and asserted-relatively in tests.

Scope

• In: --predict (pred_input 3, protein-sequence context), both classes, protein scanning.
• Out: NetCleave's --generate/--train modes and the UniProt-fetching pred_input 2 (avoids network in predict()); no vendoring.
• Not wired into the CLI (its allele-centric interface doesn't fit a cleavage predictor with flanks) — Python API only, like the other processing predictors' advanced use.

Tests

• Model-free (run in CI without an install): constructor validation (bad class, missing path).
• Model-gated on NETCLEAVE_DIR (skip when absent, mirroring test_nettcr.py): CLI-reference reproduction for both classes, kind mapping + kind_support metadata, predict_proteins with correct offset/context, c_flanks required, short-flank → empty result with 1:1 alignment, dataframe schema, determinism, subclasses.

Full suite: 238 passed, 25 skipped without the DTU/NetCleave installs; 15/15 NetCleave model tests pass with the install. Ruff clean. Version 3.15.0 → 3.16.0.

https://claude.ai/code/session_01LZahFhBSCiehXTESCYQ7wG