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:
Hello everyone,

To help diagnose the root cause, I've created a minimal script that uses only NumPy. My hypothesis is that numpy.random.RandomState.randint() produces different sequences of numbers on different architectures (ARM vs. x86) for the same seed, starting with numpy>=2.0.0.

Since I don't have access to both architectures, I would be very grateful if a community member or maintainer could run the following script on both an ARM-based machine (like an Apple Silicon Mac) and an x86-based machine (like an Intel/AMD Linux or Mac) and post the outputs. This would provide definitive proof of the underlying issue.

Minimal Test Script
This script simulates how RandomForestClassifier generates random seeds for its individual trees.

Python

```
import numpy as np
import platform

print(f"Python Version: {platform.python_version()}")
print(f"NumPy Version: {np.__version__}")
print(f"System: {platform.system()} {platform.release()}")
print(f"Architecture: {platform.machine()}")
print("-" * 30)

# We use a fixed seed to ensure the RandomState starts identically.
SEED = 123
rng = np.random.RandomState(SEED)

# In RandomForestClassifier, seeds for individual trees are generated
# using rng.randint. Let's simulate generating 10 seeds.
# The upper bound is the maximum for a 32-bit signed integer.
max_int = np.iinfo(np.int32).max
number_of_seeds = 10
seeds = rng.randint(max_int, size=number_of_seeds)

print(f"Generated {number_of_seeds} seeds with initial seed {SEED}:\n")
print(seeds)
```
Thank you in advance for the help! The results from this script will confirm the best way to patch the issue within scikit-learn to ensure reproducibility for all users.

Labels: Bug, Needs Investigation