Add oneMKL power loops for float32 and float64

[antonwolfy]

This PR adds power to mkl_umath for float32 and float64. Contiguous arrays above the usual 8192-element threshold go to v?Pow, a scalar exponent is broadcast with v?PowI and a zero increment, and everything else (small, strided, scalar base) stays on the pow loop.

Matching NumPy semantics

v?Pow returns the same values as pow on all IEEE special inputs (signed zeros, infinities, NaN, subnormals, negative bases) and is within 1 ULP of libm on random inputs. A few MKL behaviours needed handling to make the loop a drop-in replacement:

• Scalar exponent fast path. Since 2.3, NumPy computes x ** -1, 0, 0.5, 1, 2 directly (0.5 uses sqrt semantics, so (-0.0) ** 0.5 is -0.0, not +0.0 as with pow). The loop mirrors this when built against NumPy >= 2.3.
• v?Powx is not used. For exponents -0.5, 0.5 and 1.5 it returns wrong values for -0.0 and -inf (e.g. (-inf) ** 1.5 gives nan). v?PowI with a zero exponent increment uses the same kernel as v?Pow, so its values are correct, and it is as fast as v?Powx for other exponents.
• Floating-point flags. MKL's flags cannot be relied on: some are spurious (0 ** -1 also raises invalid), flags raised in MKL worker threads never reach the calling thread, and on some CPUs (seen on CI runners, most likely AVX-512) float32 domain errors such as (-1.0) ** 1.5 raise nothing at all, not even in the VM error status. So after every MKL call the loop clears MKL's flags, scans the results for nan and inf (every flag-worthy case produces one), and only then derives the flags C99 requires, as glibc raises them, from inputs and results. This makes the warnings the same on every CPU and thread count. 0 ** -inf raises nothing, since C99 allows but does not require divide by zero there.
• In-place calls (out aliasing an input) go through a 64K-element buffer so the inputs are still available for that.

Complex loops are not added: v?Pow computes exp(y*log(x)), which is not exact for integer exponents (1j**2 gives -1+1.2e-16j instead of -1+0j).

Performance

Measured on a Lunar Lake DUT (4 P-cores + 4 LP E-cores, AVX2, no AVX-512) with NumPy 2.5.4 and oneMKL 2026.2. Stock and patched np.power were timed in the same process on the same arrays, with the performance governor, turbo off, single-thread runs pinned to a P-core and 4-thread runs to the P-cores. An A/A control (stock vs stock across a patch/restore cycle) read 1.00x in every cell.

Speedup of patched over stock np.power at 1M elements:

Case	1 thread	4 threads	8 threads
float32, array ** array	2.6x	8.7x	9.0x
float32, x ** scalar (2.5, 1.5, -0.5)	2.6x	8.6x	9.2x
float64, array ** array	2.6x	8.2x	7.8x
float64, x ** scalar (2.5, 1.5, -0.5)	2.2x	7.7x	7.7x

At 10k elements, just above the threshold, the speedup is 2.3-2.6x single-threaded and about 5x threaded; at 10M it reaches 11x for float32 at 8 threads. The results scan runs on the calling thread: it costs 4-11% single-threaded and 30-45% at 4-8 threads for 1M+ elements, where the speedups would otherwise be 10-15x. Not measured yet on AVX-512 Xeons, where NumPy's own power uses SVML, so the gap there will be smaller.

Testing

• New tests in test_basic.py: special values for array and scalar exponents on both the fallback and the MKL path, in-place on either operand, and the warnings C99 requires (spelled out rather than compared with np.power, whose warnings for these edge cases differ between CPUs), including a bad element at the end of a large array, processed by an MKL worker thread.
• pytest --pyargs mkl_umath: 432 passed, 1 skipped, locally and on the DUT, at 1, 4 and 8 MKL threads.
• NumPy's test_umath.py with NumPy patched: the only failures are 12 test_unary_spurious_fpexception cases for sign, which fail identically on main and are unrelated to this change.

[jharlow-intel]

Thanks, this is really nice work! The numerics and FP-flag handling look right, and the testing is thorough: special values, in-place calls, and flags raised from MKL worker threads are all covered. A couple of small things inline.