fix(omp): park idle workers under PASSIVE policy (was spinning all cores at idle) #341

[woolcoxm]

Summary

Fixes #341 — `glm` stays at ~3000% CPU after the model finishes its answer.

Root cause

The hot-thread tuning (added in #77) seeds `OMP_WAIT_POLICY=active` so libgomp's worker team stays hot across the back-to-back per-expert matmul regions. But `active` keeps the team spinning in userspace forever between regions: once a forward pass spins the team up, every worker core keeps busy-waiting even while the engine sits blocked in `getline()` waiting for the next prompt. On a many-core host that is the sustained ~3000% CPU the reporter sees at idle.

The original comment claimed `GOMP_SPINCOUNT=200000` would "spin briefly, then yield" — but that only holds under the passive policy. Under `active`, the spincount does not actually park the threads during long idle gaps.

This was independently corroborated by `docs/METAL-M5MAX-PERF-REPORT.md`, which already diagnosed the active-spin as harmful on Apple Silicon and worked around it with `COLI_NO_OMP_TUNE`. This PR generalizes that fix to the CPU path.

The fix

Switch the wait policy to `passive` while keeping `GOMP_SPINCOUNT=200000`:

• Between back-to-back matmul regions (microseconds apart) workers are still inside their 200k-iteration spin window → stay hot → the perf(omp): keep OpenMP worker team hot to eliminate per-region wake latency #77 perf win is preserved (matmul 66.9s → 20.9s).
• During the multi-second `getline()` idle, workers exhaust the spin window in microseconds, then park on a futex → 0% CPU.

Changes

• `c/glm.c` — `active` → `passive` in the self-reexec tuning block, with corrected rationale comments
• `c/coli` — same fix in the win32 path of `env_for`
• `c/tests/test_env_defaults.py` — assertion updated `active` → `passive`
• `docs/ENVIRONMENT.md` — updated the `COLI_NO_OMP_TUNE` description

Metal/CUDA builds were already excluded from the tuning block (`!getenv("COLI_METAL") && !getenv("COLI_CUDA")`), so they are unaffected.

Verification

• `glm.c` compiles clean (no new warnings).
• All 11 buildable C tests pass; `test_env_defaults` (4 tests) passes with the updated assertion.
• `test_stops` fails to build on Windows, but I confirmed it fails identically on pristine `origin/dev` — it is a pre-existing `mkdtemp` portability issue unrelated to this change.

I could not reproduce the 3000% figure locally (my CPU does not exhibit the same spin behavior), so the reporter's confirmation on their FreeBSD host would be the definitive test.

Closes #341.