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:
I opened https://github.com/scipy/scipy/issues/20294 to get insights from Scipy developers. I also realised the issue is in the scipy 1.13 release candidate.

> Based on https://github.com/scikit-learn/scikit-learn/issues/28625#issuecomment-2007649591, libopenblas seems to be loaded twice. If this is the case, this leads to undefined behavior.
>
> I am afraid that there is not much we can do apart from recommending using conda packages instead of wheels.

This will always be the case with wheels, right? The OpenBLAS shipped with the numpy wheel and the OpenBLAS shipped with the scipy wheel will be different. This is a super common use case, we need to make sure it works ...

Labels: cython