ScaffoldSplitter hardcodes n_jobs=-1 in ScaffoldSplit calls

[smcolby]

Problem

ScaffoldSplitter.split() internally constructs splito.ScaffoldSplit with n_jobs=-1 hardcoded in all six call sites (scaffold.py lines 48, 69, 143, 163, 239, 259). This is not exposed as a configurable field on ScaffoldSplitter, so users have no way to control the parallelism used for scaffold fingerprint computation.

This causes joblib multiprocessing pool overhead even on small datasets (e.g., integration test fixtures), and prevents users from setting n_jobs=1 to avoid that overhead or to get deterministic behaviour in constrained environments.

Expected behaviour

ScaffoldSplitter should expose an n_jobs Pydantic field (defaulting to -1 to preserve current behaviour) and pass it through to all ScaffoldSplit() instantiations.

Example fix

@splitters.register("ScaffoldSplitter")
class ScaffoldSplitter(SplitterBase):
    n_jobs: int = -1

    def split(self, X, y):
        splitter = ScaffoldSplit(smiles=X, n_jobs=self.n_jobs, ...)

Affected file

openadmet/models/split/scaffold.py — ScaffoldSplitter, MaxDissimilaritySplitter, PerimeterSplitter all share this pattern.