Fix HumanEval assistant-prefix continuation

[amd-nithya]

Summary

• Keep HumanEval on /v1/completions while rendering each model's chat template locally.
• Preserve HumanEval's final assistant code prefix as an open continuation, including for tokenizers that append closing markers.
• Preserve the configured string or token-ID request format and allow the served model alias and tokenizer checkpoint to differ.
• Stage the HumanEval compatibility launcher with Magpie's benchmark scripts.
• Keep GSM8K, MMLU, and HellaSwag on the standard lm_eval invocation without HumanEval-specific flags.

Why

humaneval_instruct ends its prompt with an assistant code prefix that the model must continue. The chat-completions path treats that prefix as an already completed message, while some local chat templates append end-of-message markers even when continuation is requested. The HumanEval-only compatibility launcher renders the model-native template locally and removes only the suffix after the final assistant content.

Validation

• 248 passed across the relevant benchmark, staging, and compatibility tests.
• bash -n, Python compilation, and git diff --check passed.
• Crusoe combined smoke selected all four tasks in one run (limit=5): GSM8K 1.00, MMLU 0.867, HellaSwag 0.60, and HumanEval 1.00 (5/5).
• The combined run showed GSM8K, MMLU, and HellaSwag using normal python -m lm_eval without --apply_chat_template; only HumanEval used the compatibility launcher.
• Review regression test: HumanEval ran through a strict proxy that returned HTTP 422 for token arrays or chat objects. With tokenized_requests=false, all five requests carried string prompts and HumanEval passed 5/5.
• HumanEval continuation was also exercised across runnable Qwen, GLM, DeepSeek, and Kimi model families.

[haofrank]

Found two regressions in the HumanEval execution path. Related local tests passed (211); the lm-eval runtime test module was skipped because lm_eval is not installed locally. No GPU validation was performed.

[haofrank]

LGTM