feat: wire compile_model_if_enabled into radar, image, and audio classification

[musicalplatypus]

This is part of a 4-PR stack: #34 → #35 (this PR) → #36 → #37. Depends on #34 — please merge that first; this PR's diff includes #34's commit until it does.

Summary

compile_model_if_enabled (the torch.compile warmup-and-fallback helper added for the four timeseries_* reference scripts) was never wired into radar_classification, image_classification, or audio_classification. --compile-model was silently a no-op for these three scripts regardless of what a caller requested.

Same one-line insertion in all three files, matching the existing timeseries_classification pattern verbatim:

model = compile_model_if_enabled(model, args, logger, input_shape=(1,) + dataset.X.shape[1:])

placed between move_model_to_device and setup_distributed_model. No changes to compile_model_if_enabled itself.

Known side effect on direct script invocation (not the supported tinyml-modelmaker path): PYTORCH_ENABLE_MPS_FALLBACK=1 is set at tinyml-modelmaker's entry points, not inside tinyml-tinyverse itself. A user invoking one of these references/*/train.py scripts directly (bypassing modelmaker) with --device mps --compile-model 1 will now hard-fail on an unsupported op instead of silently ignoring the flag, since --compile-model is reachable for the first time. The supported path through modelmaker is unaffected.

Note on defaults: this PR keeps --compile-model opt-in and unchanged (default 0) for these three modules — the benchmark data below doesn't argue for changing that. A later PR in this stack (#37) does auto-enable compile_model on CUDA hardware for these three modules via apply_hardware_defaults, for consistency with how timeseries already behaves — that's a separate, explicit decision made after reviewing this PR's own CUDA numbers, not a contradiction of this PR; see #37 for the rationale.

Benchmark results

Benchmarked --compile-model on both Apple Silicon (CPU vs MPS) and an NVIDIA CUDA box (CPU vs CUDA, inductor backend) for the one or smallest registered model in each of the three modules (radar and audio currently have exactly one registered model each; image has several, smallest used). Full numbers and methodology are in docs/superpowers/plans/2026-08-13-compile-hardening-radar-image-audio.md.

Headline: results are genuinely mixed across model/device combinations. Most measured configurations regress with compile enabled — largely explainable by one-time compile warmup dominating short synthetic benchmark runs (confirmed by isolating warmup cost via 1-epoch-vs-30-epoch differential runs for two of the three modules). One module (audio) shows a concrete, non-warmup MPS-specific regression traced to a dropout op falling back to CPU under torch.compile. The CUDA inductor numbers in the plan doc's per-task tables reflect an earlier state where inductor failed to build in the test environment and fell back to eager (a local toolchain issue, since fixed) — the corrected, real inductor numbers are in that doc's later Addendum section.

CI

CI is red on all three OS jobs — pre-existing on main, same root cause and same non-involvement as noted in #34; unchanged by this PR.

Test plan

• New regression test per module confirming main()'s source calls compile_model_if_enabled (a source-presence check, not a full behavioral test — the follow-up PR feat: wire compile_model into modelmaker (explicit opt-in) + 4 review follow-ups #37 replaces these with tests that verify the call's arguments and that its return value is actually used)
• --compile-model 0 (default) verified to produce zero behavior change
• Manual E2E on all three modules, both devices where available, confirming the compile path actually engages (or falls back cleanly when the environment's toolchain can't build it)
• Full existing test suite passes locally (pre-existing CI failures noted above, unrelated)