feature: provenance-safe post-abliteration recovery pipeline

Context

PR #127 bundled a QLoRA recovery trainer and a four-source dataset downloader with the blending feature. The proposal crosses separate model-loading, remote-code, dataset-license/provenance, network, GPU, persistence, and training-correctness boundaries. It had no relevant tests, implicitly trusted remote model code, trained on padding labels, swallowed all dataset-source failures, and could publish a partial or empty corpus as if it were complete and refusal-free.

Primary class: feature-track; dataset acquisition and resulting claims are research-integrity surfaces.

Acceptance criteria

• define a versioned recovery-data schema and validate every message, role, source identifier, license field, and provenance locator;
• pin dataset repositories/configurations/splits/revisions and record content hashes plus allowed redistribution/use terms;
• describe refusal filtering as a tested heuristic, not a guarantee, with false-positive/false-negative evaluation;
• fail closed on unavailable, truncated, malformed, or underfilled sources unless an explicitly labeled partial mode is requested;
• write dataset and metadata atomically and make the exact corpus reproducible from seed plus pinned inputs;
• keep remote model code disabled by default and expose an explicit, tested opt-in;
• mask padding labels with -100, validate tokenizer padding behavior, reject empty datasets and invalid hyperparameters, and preserve prior outputs on failure;
• provide CPU unit/contract tests plus separately marked network/download and Titan GPU runtime validation;
• add locked optional dependencies and update risk-map, supply-chain, contributor, and operator documentation before merge.

The corrected delivery for PR #127 will not place this unvalidated pipeline in the importable package.