feat(mlxlm): per-record prompts for dataset-style agent tasks (GSM8K STaR)

[jayscambler]

What

The mlxlm SFT path shared one scenario-level task_prompt across all training records. That fits single-task scenarios (cap-sets, grid_ctf) but not dataset-style agent tasks like GSM8K, where each record solves a different problem. records_to_completions now uses a record's own "prompt" field when present (falling back to the scenario task_prompt), so each completion trains on its own instruction. This is the missing piece for running STaR / ReST-EM over a problem distribution through run_mlxlm_training.

Tests: per-record prompt routing + fallback; end-to-end through write_completion_dataset.

Motivation + honest finding

This was built to run a STaR self-improvement loop on GSM8K locally (Qwen2.5-0.5B-4bit): the model samples solutions to train problems, the exact-integer verifier keeps the correct chains, LoRA-SFT on them, repeat; eval on a disjoint held-out test split.

The wiring works end to end (the per-problem prompts thread correctly through training). But the result was a clean negative: held-out accuracy regressed 25% → 15% → 12.5% over two rounds. The likely causes are well-understood and point to scale, not a bug:

• Catastrophic forgetting — a 4-bit 0.5B LoRA-SFT'd on only ~25 of its own chains drifts off the instruct prior.
• Verifier false positives — GSM8K answers are integers, so lucky-wrong reasoning passes the verifier and trains bad chains.
• Sub-STaR-regime scale — STaR's results are on far larger models and thousands of problems; 0.5B / 48 problems is well below where it bootstraps.

So this PR ships the reusable infrastructure (per-record prompts) that the STaR attempt validated, independent of the negative local result. A positive GSM8K self-improvement demo needs the regime STaR actually requires (a 3B+ base, thousands of problems, gentler training, false-positive filtering) — i.e. a GPU/Modal-scale run, not local 0.5B.