v0.26.3 — fixes wrong N-D results on Intel AVX-512

Correctness fix. Upgrade if you run N-D transforms on Intel CPUs with AVX-512.

Affected: v0.25.0, v0.26.0, v0.26.1, v0.26.2, on Intel CPUs with AVX-512 (e.g. Cascade Lake, Ice Lake, Sapphire Rapids) only.

Symptom: FFTN / FFT2 / PlanN (and their inverses) returned wrong values, silently, when an axis other than the last has a length 9·p with p a prime that no Stockham pass handles — 153, 171, 207, 261, 342, … (120 of the lengths up to 2000). 1-D transforms, real transforms, the last axis, and every other CPU (AMD, Intel without AVX-512, arm64, and the other architectures) were correct.

Cause: v0.25.0's radix-9 route made compTakes16(9·p) true while the axis plan of 9·p is Rader or Bluestein; the N-D plan replaced it with a Stockham plan whose passes multiply to 9, not 9·p.

Fix (#73): the strip axis takes the no-radix-16 Stockham plan only when its passes multiply to n, and that plan's constructor now refuses (panics with an internal message) a partial factorization instead of transforming the wrong length. New tests check every strip-axis length 2–2000 and force the radix-9 route on any amd64 CPU, so CI catches this whatever runner it gets.

How it was found: FuzzPublicAPI failed once on a CI runner with AVX-512 (shape [171 22]: FFTN round trip) and passed on rerun on another runner; reproduced deterministically on Cascade Lake.