fix: harden torch.compile support against real-hardware failure modes

[musicalplatypus]

Summary

torch.compile auto-enables on CUDA (apply_hardware_defaults, a separate PR), but hitting it on real hardware surfaced several failure modes not visible from CPU-only testing: silent compile failures that never fell back, wrong keys in saved/loaded checkpoints, quantization incompatibility, and export crashes. Fixed all of them with regression tests.

torch.compile validation and fallback

torch.compile is lazy — a bad compile only surfaces on the first real forward call, not at torch.compile(model) time. Without a warmup pass, a compile failure during actual training would crash the run instead of falling back to eager mode. Added a warmup forward pass (with the correct input_shape, now threaded through all 4 call sites) inside try/except so failures genuinely fall back; the model's training mode is restored unconditionally afterward (a warmup pass run in eval mode was leaking that state into the real training loop).

Skip compile under quantization

FX-based quantization (prepare_qat_fx) cannot trace a torch.compile-wrapped model — it needs the real nn.Module graph structure, not Dynamo's compiled wrapper. compile_model_if_enabled now skips compilation entirely when quantization is enabled, with a log line explaining why, rather than letting FX tracing fail deep in the quantization pipeline with a confusing error.

Checkpoint / export correctness under torch.compile

torch.compile wraps a model as OptimizedModule, whose state_dict() keys are prefixed with _orig_mod.. This broke three separate things:

• Checkpoint save: save_checkpoint now unwraps the model (and, symmetrically, the EMA model — whose compiled wrapper nests one level deeper, at model_ema.module._orig_mod) before calling .state_dict(), so checkpoints no longer carry the _orig_mod. prefix going forward.
• Checkpoint resume: resume_from_checkpoint strips _orig_mod. from loaded checkpoint state (for compatibility with older, already-written checkpoints) and symmetrically remaps onto the live model's own current keys if it's currently compiled. Also fixes a latent unsafe-deserialization issue: torch.load(..., weights_only=False) disabled PyTorch's deserialization safety check entirely — replaced with torch.serialization.safe_globals([Namespace]), an explicit allowlist for the one non-tensor type actually stored (args).
• load_weights() (float→quantization weight transfer): had no _orig_mod. handling at all — a checkpoint saved by older code, or written by any other torch.compile-using caller, would silently discard 100% of its weights via the existing strict=False fallback with no exception raised. Added the same _orig_mod. stripping as defense-in-depth.
• Export: export_model() now recursively unwraps all compiled submodules (not just a top-level one) before copy.deepcopy(model) and ONNX/TorchScript export — a compiled submodule nested inside an otherwise-uncompiled model previously crashed export.

CI

Wires tinyml-tinyverse's test suite into CI (previously untriggered and unrun).

Verification

All of the above were found and fixed against real CUDA hardware (Blackwell GB10), not just CPU-only unit tests — the compile-warmup-fallback fix in particular was validated against a real ptxas/Triton codegen failure specific to that GPU generation, confirming the fallback path actually engages and training completes successfully in eager mode when compilation itself fails.

🤖 Generated with Claude Code

[musicalplatypus]

CI failure investigated — pre-existing on upstream/main, unrelated to this PR.

Verified directly against upstream/main's own most recent CI run (same base commit, 331388a): https://github.com/TexasInstruments/tinyml-tensorlab/actions/runs/30376872256 — it already fails identically on macOS + Ubuntu with:

FAILED test_config_validation.py::...test_task_type_is_valid[google_speech_command/config_MSPM0.yaml] - unknown task_type='audio_classification'
FAILED test_config_validation.py::...test_model_name_exists_in_registry[...] - model 'DSCNN_NPU' not in registry

This PR's CI run shows only that same subset — no new failures introduced. It's fixed in #19; should resolve automatically once that merges. (Windows failures don't block merging — the workflow marks that runner continue-on-error: true.)