BUG: `pd.Timestamp()` only raises for nonexistent times when instantiated using str `ts_input`

[leonoverweel]

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

# Nonexistent time, but doesn't raise:
t1 = pd.Timestamp(2023, 3, 26, 2, 0, 0, tz="Europe/Amsterdam")

# Same nonexistent time, but does raise:
t2 = pd.Timestamp("2023-03-26 02:00", tz="Europe/Amsterdam")

Issue Description

When instantiating a nonexistent time, I would expect both ways of instantiating that time -- (1) using the year, month, day, hour, minute parameters and (2) using a (string) ts_input parameter -- to have the same result.

However, option (1) happily accepts this nonexistent time, while option (2) correctly raises a pytz.NonExistentTimeError

Full traceback

Traceback (most recent call last):
  File "../example.py", line 16, in <module>
    dt2 = pd.Timestamp("2023-03-26 02:00", tz="Europe/Amsterdam")
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pandas/_libs/tslibs/timestamps.pyx", line 1667, in pandas._libs.tslibs.timestamps.Timestamp.__new__
  File "pandas/_libs/tslibs/conversion.pyx", line 280, in pandas._libs.tslibs.conversion.convert_to_tsobject
  File "pandas/_libs/tslibs/conversion.pyx", line 547, in pandas._libs.tslibs.conversion.convert_str_to_tsobject
  File "pandas/_libs/tslibs/tzconversion.pyx", line 177, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc_single
  File "pandas/_libs/tslibs/tzconversion.pyx", line 417, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc
pytz.exceptions.NonExistentTimeError: 2023-03-26 02:00:00

Expected Behavior

Both options (1) and (2) for instantiating a nonexistent time should raise and tell me it's a nonexistent time.

Installed Versions

INSTALLED VERSIONS
------------------
commit           : 0f437949513225922d851e9581723d82120684a6
python           : 3.11.4.final.0
python-bits      : 64
OS               : Darwin
OS-release       : 22.3.0
Version          : Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
machine          : arm64
processor        : arm
byteorder        : little
LC_ALL           : None
LANG             : None
LOCALE           : en_US.UTF-8

pandas           : 2.0.3
numpy            : 1.25.2
pytz             : 2023.3
dateutil         : 2.8.2
setuptools       : 68.0.0
pip              : 23.2.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       : None
brotli           : None
fastparquet      : None
fsspec           : None
gcsfs            : None
matplotlib       : None
numba            : None
numexpr          : None
odfpy            : None
openpyxl         : None
pandas_gbq       : None
pyarrow          : None
pyreadstat       : None
pyxlsb           : None
s3fs             : None
scipy            : None
snappy           : None
sqlalchemy       : None
tables           : None
tabulate         : None
xarray           : None
xlrd             : None
zstandard        : None
tzdata           : 2023.3
qtpy             : None
pyqt5            : None

[xzmeng]

I cannot find it documented that pandas.Timestamp should raise a NonExistentTimeError if the timestamp falls in the gap of DST transition.
https://pandas.pydata.org/docs/reference/api/pandas.Timestamp.html

pandas now only raise NonExistentTimeError when localizing a timeseries.
http://pandas.pydata.org/docs/user_guide/timeseries.html#nonexistent-times-when-localizing

Even so, I think it is still necessary to unify the behavior of pd.Timestamp for different input_ts.