Fix GSM8K generation evaluation

[amd-nithya]

Summary

• isolate GSM8K generation from likelihood tasks and stop at the next Question: marker
• retain sample logs for GSM8K and HumanEval without enabling --write_out by default
• keep HumanEval chat-template and unsafe-code flags scoped to its dedicated invocation
• leave MMLU and HellaSwag completion/log-likelihood behavior unchanged

Validation

• .venv/bin/python -m pytest -q tests/test_eval_concurrency_scripts.py (51 passed)
• MiniMax-M2.5 GSM8K canary: 0.26 -> 0.85 (20 samples)
• DeepSeek-V4 GSM8K canary: 0.02 -> 0.75 (20 samples)
• all-four GLM regression: MMLU 0.8781, HellaSwag 0.80, GSM8K 0.90, HumanEval 0.95

Per-sample canary artifacts were inspected: the remaining DeepSeek misses were reasoning errors rather than parser failures.

Companion Crystal integration: https://github.com/AMD-AI-CHIEF-OF-STAFF/Crystal/pull/37

[amd-nithya]

Addressed all three review comments in 8dd9218:

• Preserve an explicit MAGPIE_EVAL_CONFIRM_UNSAFE_CODE=true opt-in for other unsafe tasks such as MBPP after HumanEval is isolated.
• Use HumanEval sample logging's effective default when deciding whether to isolate it in mixed suites.
• Isolate GSM8K before stock-include routing, while preserving the correct include path for its dedicated invocation.

Added a regression test for each case. Validation: tests/test_eval_concurrency_scripts.py passes (54 tests), Bash syntax validation passes, and the broader related eval set reached 96 passes; the remaining local runtime checks require unavailable optional dependencies or sandbox permissions.

[haofrank]

LGTM