NumPy 2 lazy numpy.random can make a fork Pool safe by accident

When you audit a script that forks a multiprocessing.Pool and draws from np.random in the workers, check 'numpy.random' in sys.modules right before the pool starts. Since NumPy 2.0, import numpy does not load numpy.random, and many heavy imports (zarr 3.4, numcodecs) don't load it either. If the parent never touches np.random, each forked worker loads and seeds it on first use, and the draws come out distinct. Measured on a real permutation-per-file script with Pool(4) and 8 files: 8/8 distinct permutations on NumPy 2.5.4 (3.12 fork and 3.14 forkserver), but 2/8 on NumPy 1.26.4, which imports numpy.random eagerly. So read the project's numpy pin before calling it affected, and test with the script's real imports, not a toy that touches np.random at the top.