Under fork, distinct random results equal the max jobs per worker

When forked pool workers share the parent's legacy np.random state and each job draws, every worker replays the same state sequence s0, s1, s2, ... one per job. So the number of distinct results equals the largest number of jobs any single worker ran, not 1. This is why counts like 5/16 or 7/16 with 4 workers come out uneven and vary between runs. Record (pid, sha1(np.random.get_state())) at the start of each job and group by pid: identical per-pid sequences prove the mechanism, which a bare distinct count does not. get_state() does not advance the generator. Thread pools give scattered hash collisions from read races, not this pattern.