fix(service): wrap Windows execution with cmd /c

[dnzgrkn]

…es from working dirJava's ProcessBuilder on Windows resolves command names against PATH
only — it does not search the working directory the way Unix shells
do. So even after CommandRunner.adaptForOs() translated "./main"
into "main.exe", Windows couldn't find the executable that gcc had
just produced in the per-submission temp working dir, and every run
failed with Cannot run program "main.exe" (in directory "...").

Fix: on Windows, prefix the execute() command with "cmd" "/c" so the
Windows shell handles resolution. Linux/macOS path unchanged.

Verified locally with the design-doc-standard runCommand "./main" and
Emre's six fixtures:

• 20240001 → PASS
• 20240002 → COMPILE_ERROR (gcc detects missing semicolon)
• 20240003 → TIMEOUT (infinite loop killed after 10s)
• 20240004 → FAIL (output mismatch detected by OutputComparator)
• 20240005 → COMPILE_ERROR (source file not found)
• 20240006 → COMPILE_ERROR (corrupt ZIP rejected by ZipExtractor)

Lets us ship examples/configurations/c_standard.json with the portable
"./main" rather than a Windows-only workaround.