PowerTransformer's standardize sensitive to small differences in data, with MinMaxScaler unable to scale

### Describe the bug

Edit - when I wrote "sensitive to small differences in data",  I meant the different outputs when a value is changed from 4.61 to 4.62 as shown below.   
Edit2 - I'm not sure this should be even flagged as a bug, rather it's an unexpected result that arises when you really shouldn't use PowerTransformer on certain data. However, users might apply the PowerTransformer on hundreds of features at once, and perhaps the situation described below could raise a warning?

Hello,  
I'm trying to test how a Yeo-Johnson transformation might affect a model I'm working on (however, this issue is related to standardization rather than to the Yeo-Johnson transformation itself).  
For certain features, which aren't well suited for a Yeo-Johnson or Box-Cox transformation, the algorithm returns extremely similar values (when standardize=False), with differences only in the last few significant digits. This is consistent with scipy's `yeojohnson` and behaving as intended. However, then the standardization (standardize=True) can either yield unexpected results, or not, depending on small differences in the original data. 

In one of such cases, the standardization (standardize=True) returns values that maintain the original trend, but are very small, in the order of 10^-17. This behavior of the standardization algorithm is very sensitive to minimal differences in the original data, as if I change just a 4.62 value to 4.61, it succeeds and creates a standardized array with a reasonable value range, I would say masking these very small differences in the original transformed array; while sometimes it doesn't succeed and yields a standardized array with values of ~10^-17, as mentioned above.  
Furthermore, when the standardized data is in the 10^-17 range, even MinMaxScaler can't scale properly these values, which remain in the order of 10^-17.   




I have included a simple array of 10 observations that can reproduce the issue.  

In the example, the initial value of data[0, 0] is 4.61, which superficially doesn't show issues when using `standardize=True`. Here, PowerTransformer returns a range of values from -1.04 to 2.58, which follow the original trend and can be further transformed by the MinMaxScaler to the range (0, 1).    

With minimal differences to the original data, i.e. if data[0, 0] is 4.62, PowerTransformer's standardization returns values in the range of -10^-18 to 0, so extremely close to 0; and MinMaxScaler retains the proportionalities, but doesn't scale them properly.  

With `standardize=False`, the method returns the transformed values, which as mentioned above are very close, down to almost the last significant digit, and MinMaxScaler is unable to scale them.  


### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.preprocessing import PowerTransformer, MinMaxScaler

data = np.array([[4.61],
                 [4.56],
                 [4.59],
                 [4.56],
                 [4.71],
                 [5.63],
                 [4.66],
                 [4.67],
                 [4.70],
                 [4.61]])

for value in range(2):
    # Tests with 4.61 and 4.62
    data[0, 0] += value * 0.01
    print(f"\nWhen data[0, 0] is: {data[0, 0]}")
    pt = PowerTransformer(standardize=True) # ALSO TRY WITH: `standardize=False`
    data_pt = pt.fit_transform(data)
    print("\nAfter Powertransformer:")
    print(data_pt)
    mms = MinMaxScaler(feature_range=(0,1))
    data_mms = mms.fit_transform(data_pt)
    print("\nAfter MinMaxScaler:")
    print(data_mms)
```

### Expected Results

Power-transformed data, and scaled data in the range (0, 1)

### Actual Results

```
When data[0, 0] is: 4.61

After Powertransformer:
[[-0.45266018]
 [-1.04111841]
 [-0.67899027]
 [-1.04111841]
 [ 0.40739416]
 [ 2.58016302]
 [ 0.04526602]
 [ 0.09053204]
 [ 0.36212814]
 [-0.45266018]]

After MinMaxScaler:
[[0.1625]
 [0.    ]
 [0.1   ]
 [0.    ]
 [0.4   ]
 [1.    ]
 [0.3   ]
 [0.3125]
 [0.3875]
 [0.1625]]

When data[0, 0] is: 4.62

After Powertransformer:
[[-4.16333634e-17]
 [-1.17961196e-16]
 [-7.63278329e-17]
 [-1.17961196e-16]
 [ 4.16333634e-17]
 [ 2.77555756e-16]
 [ 0.00000000e+00]
 [ 6.93889390e-18]
 [ 4.16333634e-17]
 [-5.55111512e-17]]

After MinMaxScaler:
[[7.63278329e-17]
 [0.00000000e+00]
 [4.16333634e-17]
 [0.00000000e+00]
 [1.59594560e-16]
 [3.95516953e-16]
 [1.17961196e-16]
 [1.24900090e-16]
 [1.59594560e-16]
 [6.24500451e-17]]
```

### Versions

```shell
System:
    python: 3.12.4 | packaged by conda-forge | (main, Jun 17 2024, 10:04:44) [MSC v.1940 64 bit (AMD64)]
executable: C:\Users\Roberto\miniconda3\envs\ml2\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.5.1
          pip: 24.1.2
   setuptools: 72.1.0
        numpy: 2.0.1
        scipy: 1.14.0
       Cython: None
       pandas: 2.2.2
   matplotlib: 3.9.1
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libscipy_openblas
       filepath: C:\Users\Roberto\miniconda3\envs\ml2\Lib\site-packages\numpy.libs\libscipy_openblas64_-fb1711452d4d8cee9f276fd1449ee5c7.dll
        version: 0.3.27
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: vcomp
       filepath: C:\Users\Roberto\miniconda3\envs\ml2\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None

       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libscipy_openblas
       filepath: C:\Users\Roberto\miniconda3\envs\ml2\Lib\site-packages\scipy.libs\libscipy_openblas-5b1ec8b915dfb81d11cebc0788069d2d.dll
        version: 0.3.27.dev
threading_layer: pthreads
   architecture: Haswell
```

COMMENT:
Thanks for the report and analysis.

The difference between the minimum and maximum YJ-transformed data prior to standardization is 5.551115123125783e-16 on the original data while it is 3.95516952522712e-16 on the updated data with `data[0, 0] == 4.62`,

This makes `StandardScaler` switch between considering the YJ-transformed feature numerically near-constant or not based on the rule implemented in `_is_constant_feature`:

https://github.com/scikit-learn/scikit-learn/blob/21e1642b0b47475ffd476c9df6c9984d71b90b1d/sklearn/preprocessing/_data.py#L66-L79

When a feature is considered numerically near-constant by `StandardScaler`, only mean removal is applied (and not standard-deviation scaling) to avoid numerical problems in downstream estimators:

https://github.com/scikit-learn/scikit-learn/blob/21e1642b0b47475ffd476c9df6c9984d71b90b1d/sklearn/preprocessing/_data.py#L1011-L1019

I suspect we could try to detect that if a feature wasn't numerically near-constant before applying YJ but becomes after YJ (before applying `StandardScaler`) we can raise a warning indeed. Detecting this will cause some redundant computation though.

Note that in our YJ code, if an input feature is detected as numerically near-constant, we already leave them unchanged:

https://github.com/scikit-learn/scikit-learn/blob/21e1642b0b47475ffd476c9df6c9984d71b90b1d/sklearn/preprocessing/_data.py#L3288-L3301

Labels: Bug