BUG: `pd.cut` with `IntervalIndex` produces unexpected results when `freq` of data and bins differ

[bollard]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd

bins = {
    "0D": (0, 1),
    "1D-2W": (1, 14),
    "2W-6M": (14, 365 / 2),
    "6M+": (365 / 2, None),
}

# convert bins to pd.Timedelta, inserting an arbitrary maximum value
bins = [
    (pd.Timedelta(days=left), pd.Timedelta(days=right or pd.Timedelta.max.days))
    for left, right in bins.values()
]

# convert bins to pd.IntervalIndex
idx = pd.IntervalIndex.from_tuples(bins, closed="left")

# inspect dtype - note ns
idx.dtype

# interval[timedelta64[ns], left]

# construct pd.Series
ser = pd.Series([
    pd.Timedelta(0, unit="days"),
    pd.Timedelta(10, unit="days"),
    pd.Timedelta(100, unit="days")
])

# all results are put into the (0, 1) day bin
pd.cut(ser.astype("timedelta64[ms]"), bins=idx)

# 0    [0 days 00:00:00, 1 days 00:00:00)
# 1    [0 days 00:00:00, 1 days 00:00:00)
# 2    [0 days 00:00:00, 1 days 00:00:00)
# dtype: category
# Categories (4, interval[timedelta64[ns], left]): [[0 days 00:00:00, 1 days 00:00:00) < [1 days 00:00:00, 14 days 00:00:00) < [14 days 00:00:00, 182 days 12:00:00) < [182 days 12:00:00, 106751 days 00:00:00)]

# data are correctly binned
pd.cut(ser.astype("timedelta64[ns]"), bins=idx)

# 0       [0 days 00:00:00, 1 days 00:00:00)
# 1      [1 days 00:00:00, 14 days 00:00:00)
# 2    [14 days 00:00:00, 182 days 12:00:00)
# dtype: category
# Categories (4, interval[timedelta64[ns], left]): [[0 days 00:00:00, 1 days 00:00:00) < [1 days 00:00:00, 14 days 00:00:00) < [14 days 00:00:00, 182 days 12:00:00) < [182 days 12:00:00, 106751 days 00:00:00)]

Issue Description

Hi all,

I've noticed that when the resolution of the pd.IntervalIndex used to construct the bins, and the pd.Series of values to be binned differ, pd.cut produces unexpected outputs.

I can understand comparing different resolutions can maybe lead us into undefined behaviour territory, but I would at the very least expect a warning and maybe even an error. To give back the incorrect result with no notification to the user is prime for producing bugs.

Thanks

Expected Behavior

Either pd.cut to produce the "right" answer (i.e. as per pd.cut(ser.astype("timedelta64[ns]"), bins=idx)), or a warning or error to be raised

Installed Versions

pd.show_versions()
C:\Miniconda3-py37_4.10.3\envs\py311pandas\Lib\site-packages_distutils_hack_init_.py:33: UserWarning: Setuptools is replacing distutils.
warnings.warn("Setuptools is replacing distutils.")

INSTALLED VERSIONS

commit : a671b5a
python : 3.11.7.final.0
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.19045
machine : AMD64
processor : Intel64 Family 6 Model 165 Stepping 3, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_United Kingdom.1252

pandas : 2.1.4
numpy : 1.26.3
pytz : 2023.3.post1
dateutil : 2.8.2
setuptools : 68.2.2
pip : 23.3.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader : None
bs4 : None
bottleneck : 1.3.5
dataframe-api-compat: None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : 2.8.7
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None