…TRAIN-003/004 falsifier-parity coverage

Closes the parallel-implementation falsifier-coverage gap for the contract
`apr-cli-distill-train-v1.yaml` between:
  - canonical `crates/aprender-train/src/distill/loss.rs` (task #186, has tests)
  - parallel  `crates/aprender-train/src/hf_pipeline/distillation/loss.rs` (this PR)

Both implement Hinton-style KD loss with the same math invariants per
contract. Without same-coverage gates, one impl could regress without the
other surfacing — exactly the `feedback_coverage_contracts_coevolution`
class.

Adds 4 new tests to `hf_pipeline::distillation::tests`:
1. `falsify_apr_distill_train_003_t_scaling_preserves_argmax` — mirror of
   the canonical TRAIN-003 test (T-scaling preserves softmax argmax)
2. `falsify_apr_distill_train_004_alpha_one_equals_pure_kd` — mirror of
   the canonical TRAIN-004 test (alpha=1 → pure KD; the 1-alpha CE term
   is zeroed)
3. `falsify_apr_distill_train_004_alpha_zero_equals_pure_ce` — symmetric
   bookkeeping (alpha=0 → pure CE; catches off-by-one swap of alpha and
   1-alpha coefficients)
4. `falsify_apr_distill_train_003_log_softmax_consistency` — softmax/
   log_softmax inverse identity within fp32 noise + l2_normalize smoke
   to cover all three currently-imported helpers

Five Whys:
1. Why this gap? `hf_pipeline::distillation::DistillationLoss` is a
   parallel implementation of the canonical `distill::loss::DistillationLoss`,
   added later. The falsifier tests for the canonical impl (#186) weren't
   replicated.
2. Why catch it now? PRs #1432-#1434 fixed the `--features hub` build
   chain (broken syntactic + alignment-padding bugs that prevented the
   tests from being run at all). Now that the test surface is reliable,
   adding the parity coverage is finally executable.
3. Why two impls in the first place? `hf_pipeline` was a Hugging-Face-
   transformers-style scaffolding for distillation export pipelines;
   `distill::loss` is the canonical training-side loss used by `apr
   distill --stage train`. Both should compute the same math.
4. Why a TRAIN-004-dual? Same operational invariant from both directions:
   alpha=1 → soft only, alpha=0 → hard only. If a refactor swaps the
   coefficients, only one of the two tests would catch it; both together
   cover the bookkeeping completely.
5. Why no contract version bump? `apr-cli-distill-train-v1.yaml` v1.0.0
   already enumerates TRAIN-003 and TRAIN-004; this PR closes a coverage
   gap, not a contract change.

Verified locally:
- `cargo test -p aprender-train --lib --features hub falsify_apr_distill`
    → 7 pass / 0 fail (canonical 3 + new hf_pipeline 4)
- `cargo test -p aprender-train --lib --features hub` → 7990/7990 pass,
    16 ignored (was 7986 pre-PR; +4 for the new tests)
- `cargo fmt --all -- --check` → no diff in touched file

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>