BUG: nanquantile dtype depends on first slice NaN pattern - #32833

PR summary

Closes #32832.

nanquantile/nanpercentile (and the other nan-functions sharing the _nanquantile_ureduce_func path) returned a dtype that depended on whether the FIRST slice happened to be all-NaN: an all-NaN first slice silently flipped the result between float32 and float64 relative to an identical call whose first slice contained data. The result dtype should not depend on the NaN pattern of the first slice. This fixes the dtype selection so it is consistent regardless of which slices are all-NaN, and adds regression coverage across float16/32/64, 13 method variants, and several q shapes.

First time contributor introduction

First-time NumPy contributor. I found this bug through issue triage and reproduced it directly from the report in #32832 before preparing the fix.

AI Disclosure

AI assistance (Instinct assisted) was used in the preparation of this PR: the fix and regression tests were drafted with AI assistance under my direction, and I directed and approved the submission. The test runs were executed on a CPU runner in the assistant's environment: the checkout's pure-Python numpy/lib/_nanfunctions_impl.py loaded atop an installed NumPy 2.5.3 compiled runtime (no fresh from-source build; the runner bypasses one compiled-API import that is irrelevant to this module). Full test_nanfunctions.py: 1319 passed, 86 skipped with the patch; the 32 new regression cases fail without it (red-green verified).

Additional context

• Base: f99b1a0 (current main at time of branching).
• No claim of a built-from-source NumPy suite run; happy to run anything further maintainers point me at.