Parallelize GenPlan training evaluation

[joshnroy]

Summary

• evaluate GenPlan training seeds with three isolated worker processes per replicate
• use spawn and reconstruct one Kindergarden environment per worker, avoiding forks of loaded MuJoCo contexts
• collect outcomes by seed index so scheduling cannot affect feedback selection or score reduction
• expose num_score_workers with a default of 3

Stack

Stacked on the rollout-reuse PR. The lower PR establishes one authoritative outcome set; this PR evaluates that set concurrently.

Simulator-only benchmark

Using the real generalized Obstruction2D environment, ten deterministic hanging-policy tasks, a 2-second timeout, and no Claude calls:

• serial: 20.14 s
• three workers: 9.86 s
• measured speedup: 2.04x

A separate 0.5-second-timeout run measured 1.32x because environment/process startup dominates very short tasks. With the production 60-second timeout, the theoretical timeout-heavy ceiling is 2.5x (ten seeds in four three-worker waves), but this PR reports the measured 2.04x.

Verification

• pytest -q tests/utils/test_genplan_validate.py tests/approaches/test_llm_genplan_approach.py (38 passed)
• serial and parallel evaluation produce identical ordered feedback and aggregate scores
• hanging workers are terminated and represented as timeouts
• benchmark invoked only local generated-policy evaluation; it did not invoke Claude Code

Risk

Each scoring worker constructs an independent environment. This preserves seeds and evaluation settings but raises peak CPU and memory use. Three workers is chosen for a host running three concurrent replicates (nine peak simulators on 24 physical cores).