Different Results on ARM and x86 when using `RFECV(RandomForestClassifier())`

### Describe the bug

When using  `RFECV(RandomForestClassifier())` with `sklearn=1.7.1` with `numpy>=2.0.0`, I am seeing significant discrepancies in floating point results between ARM Macs and x86 Macs/Linux machines. This discrepancy goes away when I downgrade to `numpy=1.26.4`

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd

from sklearn.ensemble import RandomForestClassifier
from sklearn.feature_selection import RFECV


def _extract_rfe_scores(rfecv):
    grid_scores_ = rfecv.cv_results_['mean_test_score']
    n_features = len(rfecv.ranking_)
    # If using fractional step, step = integer of fraction * n_features
    if rfecv.step < 1:
        rfecv.step = int(rfecv.step * n_features)
    # Need to manually calculate x-axis, grid_scores_ is a 1-d array
    x = [n_features - (n * rfecv.step)
         for n in range(len(grid_scores_)-1, -1, -1)]
    if x[0] < 1:
        x[0] = 1
    return pd.Series(grid_scores_, index=x, name='Accuracy')

np.random.seed(0)
X = np.random.rand(50, 20)
y = np.random.randint(0, 2, 50)

exp = pd.Series([
            0.4999999999999999, 0.52, 0.52, 0.5399999999999999,
            0.44000000000000006, 0.52, 0.4600000000000001,
            0.5599999999999998, 0.52, 0.52, 0.5, 0.5399999999999999, 0.54,
            0.5599999999999999, 0.47999999999999987, 0.6199999999999999,
            0.5399999999999999, 0.5, 0.4999999999999999, 0.45999999999999996],
            index=pd.Index(range(1, 21)), name='Accuracy')

selector = RFECV(RandomForestClassifier(
    random_state=123, n_estimators=2), step=1, cv=10)
selector = selector.fit(X, y.ravel())
selector_series = _extract_rfe_scores(selector)

pd.testing.assert_series_equal(selector_series, exp)
```

### Expected Results

I expect the resulting `selector_series` to be equal to `exp` or

```
 [0.4999999999999999, 0.52, 0.52, 0.5399999999999999,
  0.44000000000000006, 0.52, 0.4600000000000001,
  0.5599999999999998, 0.52, 0.52, 0.5, 0.5399999999999999, 0.54,
  0.5599999999999999, 0.47999999999999987, 0.6199999999999999,
  0.5399999999999999, 0.5, 0.4999999999999999, 0.45999999999999996]
```

across all architectures as was the case previously.


### Actual Results

I am seeing the expected result when using ARM Macs; however, when using x86 Macs or Linux I am seeing the following significantly different series.

```
 [0.5, 0.5, 0.4800000000000001, 0.6199999999999999,
  0.6000000000000001, 0.62, 0.56,
  0.5, 0.54, 0.45999999999999996, 0.44000000000000006, 0.6399999999999999, 0.52, 
  0.45999999999999996, 0.47999999999999987, 0.6, 
  0.5599999999999999, 0.5, 0.47999999999999987, 0.45999999999999996]
```

### Versions

```shell
System:
    python: 3.12.3 | packaged by conda-forge | (main, Apr 15 2024, 18:38:13) [GCC 12.3.0]
executable: /home/anthony/miniconda3/envs/test/bin/python
   machine: Linux-6.8.0-78-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.7.1
          pip: 25.1
   setuptools: 78.1.1
        numpy: 2.2.6
        scipy: 1.16.1
       Cython: None
       pandas: 2.3.1
   matplotlib: None
       joblib: 1.5.1
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /home/anthony/miniconda3/envs/test/lib/libomp.so
        version: None
```

COMMENT:
@yogeshbawankar I ran your script on my x86 Linux machine with numpy 2.2.6 and had a colleague do the same on their m3 mac. We both got the following

```
[ 843828734  914636141 1228959102 1840268610  974319580  819844194
  220395238  941243409  942612051 2109339754]
```

Labels: Bug, Needs Investigation