BUG: ArgKmin64 on Windows with scipy 1.13rc1 or 1.14.dev times out

In MNE-Python our Windows [pip-pre job on Azure has started reliably timing out](https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=29467&view=logs&jobId=dded70eb-633c-5c42-e995-a7f8d1f99d91&j=dded70eb-633c-5c42-e995-a7f8d1f99d91&t=d18f7f2f-13af-5901-1cbc-7fa039d0db3a) (and a [second example](https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=29468&view=logs&j=b9064c46-2375-5b70-72c1-f55d0d61c63a&t=22e60518-c9c9-558d-d42d-7392b6cf8931)):
```
mne/preprocessing/tests/test_interpolate.py::test_find_centroid PASSED   [ 38%]
##[error]The Operation will be canceled. The next steps may not contain expected logs.
Fatal Python error: PyThreadState_Get: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: initialized

...
Thread 0x000014fc (most recent call first):
  File "C:\hostedtoolcache\windows\Python\3.11.8\x64\Lib\site-packages\sklearn\metrics\_pairwise_distances_reduction\_dispatcher.py", line 278 in compute
  File "C:\hostedtoolcache\windows\Python\3.11.8\x64\Lib\site-packages\sklearn\neighbors\_base.py", line 850 in kneighbors
  File "C:\hostedtoolcache\windows\Python\3.11.8\x64\Lib\site-packages\sklearn\neighbors\_lof.py", line 291 in fit
  File "C:\hostedtoolcache\windows\Python\3.11.8\x64\Lib\site-packages\sklearn\base.py", line 1474 in wrapper
  File "C:\hostedtoolcache\windows\Python\3.11.8\x64\Lib\site-packages\sklearn\neighbors\_lof.py", line 256 in fit_predict
  File "D:\a\1\s\mne\preprocessing\_lof.py", line 89 in find_bad_channels_lof
  File "<decorator-gen-627>", line 12 in find_bad_channels_lof
  File "D:\a\1\s\mne\preprocessing\tests\test_lof.py", line 31 in test_lof
...
```
Our code just calls the following (and hasn't been changed):
```
    clf = LocalOutlierFactor(n_neighbors=n_neighbors, metric=metric)
    clf.fit_predict(data)
```
which eventually in the traceback points to the line:

https://github.com/scikit-learn/scikit-learn/blob/e5ce4bc0f6eb8fe21cd4e3dcebabefcc5485f907/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py#L278

18 hours ago all our tests passed [in 40 minutes](https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=29454&view=logs&jobId=dded70eb-633c-5c42-e995-a7f8d1f99d91), then 3 hours ago it started [failing 38% through the tests with a 70 minute timeout](https://dev.azure.com/mne-tools/mne-python/_build/results?buildId=29460&view=logs&jobId=dded70eb-633c-5c42-e995-a7f8d1f99d91&j=dded70eb-633c-5c42-e995-a7f8d1f99d91&t=d18f7f2f-13af-5901-1cbc-7fa039d0db3a), and gets to the point only ~27 minutes into the build:

![image](https://github.com/scikit-learn/scikit-learn/assets/2365790/bb3c2997-dae5-435e-92e7-6af0bb7cd2fb)

This suggests that the latest scientific-python-nightly-wheels upload of scikit-learn (and/or NumPy) 11 hours ago caused something in here to hang, so probably some recent PR to sklearn or NumPy is the culprit.

Not exactly a MWE -- I'm not on Windows at the moment but could switch at some point -- but maybe someone has an idea about why it's happening...?

COMMENT:
Setting `OPENBLAS_NUM_THREADS=1` or `OMP_NUM_THREADS=1` seems to get rid of the issue, maybe a reasonable work-around in the short term (using threadpoolctl in a single test is an alternative if setting an environment variable is not convenient).

I am wondering if this is not due to nested parallelism OpenBLAS withing OpenMP in our neighbors code, not sure how this would be related to scipy-dev though.

Labels: cython