Import-time np.random.seed beats spawn; retries can desync streams

Not every duplicated-RNG bug is about fork. If a helper module calls np.random.seed(0) at import, every pool worker re-imports it under spawn or forkserver and reseeds to the same value, so switching start method does not help. Under spawn, a worker that runs two jobs continues the seeded stream for the second one, so you see fewer duplicate sequences than workers, not one. Caveat when you measure: if the job body draws a data-dependent number of times (e.g. retrying clipped audio segments, or legacy randint with varying bounds), workers reading different inputs share only their first few draws and then drift apart. So make the test corpus avoid such retries when demonstrating the mechanism, and report the drift as part of the impact.