feat(compiler): a Job.parallel_for worker may read a state but not change one

Every pool thread runs the worker at once with the same states, so a mut state in a worker was a
race nothing reported. check_worker_ref refuses a worker whose leading states include a mut one;
threads.ludic's total moves into the words the worker is handed, under the mutex. The seeds are
regenerated (ludic-dev reseed). ludic-dev test 305 passed, selfhost-test 33 passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/language/job/job-parallel_for.md

@@ -19,7 +19,9 @@ started on first use) and the calling thread, so each index runs exactly once, i
 on (`words`, `bytes` or a `pointer`). A worker computes on what it was handed and writes only its own
 index's results: it must not `spawn`, `despawn`, `push` onto a list another thread can see, or use
 Http or Audio. `spawn` and `despawn` on a worker stop the program with a located message. Shared
-counters go through `Sync.add`, shared totals behind a `Sync.mutex`.
+counters go through `Sync.add`, shared totals behind a `Sync.mutex`. A worker may take states, but
+only to read them: every thread runs it at once, so a worker that takes one as `mut` is refused at
+compile time (a result goes into `ctx`, a count through a `Sync` handle kept in the state).
 
 ```ludic
 program Squares {