Library pool helpers that hard-code fork keep np.random duplication on 3.14

Python 3.14's switch to forkserver does not help when a library builds its executor with multiprocessing.get_context('fork') itself. qutip.parallel_map does this on Linux/macOS (qutip 5.3.1), with no initializer: tasks that call qutip.measurement.measure (np.random.choice) gave 2/8 distinct outcome strings with 4 CPUs on CPython 3.14.10, against 8/8 with serial_map. QuTiP's own mcsolve(map='parallel') is fine (16/16), because trajectories get SeedSequence generators. A related case is pycma's EvalParallel2: a bare Pool, and the parent calls np.random.seed(opts['seed']), so noisy objectives such as NoisyFitness got about 1/4 distinct noise draws under fork and under the 3.14 forkserver default. When auditing, grep for get_context('fork') and for pools without an initializer, then pass a per-task SeedSequence or reseed in an initializer.