Make the np.dot fit deterministic across CPU thread counts #67

Finding (as written in the restart doc, MorphoFeature #130 review): with normalization.scope: plane plus zscore, normalization's np.dot makes the fitted scale depend on the CPU thread count (observed values differ: …030 vs …531). The fit is keyed in the cache, so a cached fit can differ from a fresh one.

Suggested fix: replace the BLAS-dependent np.dot in the fit with a deterministic sum (a fixed-order reduction, e.g. math.fsum or a pairwise sum in a fixed order), so the result is bitwise identical for any thread count. Add a test that compares fits under different OMP_NUM_THREADS, and check whether the cache key must change.

Source: restart doc LIVE STATE, MorphoFeature #130 review finding (2026-11-04); the item is "#130 finding: normalization np.dot thread-dependent fit, use a deterministic sum".