BUG: IntervalArray silently builds interval[int64] with an object-dtype right side

[jbrockmendel]

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

arr = pd.arrays.IntervalArray([pd.Interval(0, 2**64)])

arr.dtype          # interval[int64, right]
arr.dtype.subtype  # int64
arr.left.dtype     # int64
arr.right.dtype    # object     <- contradicts the advertised subtype
arr.length.dtype   # object
arr.mid.dtype      # object

# the mirror image, with the oversized value on the left, is rejected
pd.arrays.IntervalArray([pd.Interval(-(2**64), 0)])
# TypeError: category, object, and string subtypes are not supported for IntervalArray

pd.IntervalIndex([pd.Interval(0, 2**64)]) produces the same inconsistent state.

Issue Description

When only the right endpoint falls outside the int64 range, IntervalArray builds an array
whose declared dtype disagrees with its own data: dtype says interval[int64, right] while
right.dtype is object. Every derived quantity inherits the inconsistency (length, mid),
and arr.astype(arr.dtype) does not repair it.

IntervalArray._ensure_simple_new_inputs only ever consults left.dtype:

• the object/category/string rejection checks left.dtype alone
  (interval.py:324), so an object
  right side passes;
• the dtype is then derived from left.dtype alone
  (interval.py:365);
• the signed/unsigned mismatch check
  (interval.py:370-378)
  requires both left_dtype.kind and right_dtype.kind to be in "iu", so an object right
  side (kind "O") skips that guard too.

The asymmetry is the clearest symptom: putting the oversized value on the left raises a clean
TypeError, while putting it on the right silently produces a corrupt array.

Expected Behavior

Either outcome would be consistent; the current side-dependent behavior is not:

• raise the same TypeError regardless of which endpoint has the unsupported dtype, or
• derive the subtype from both endpoints so the resulting dtype actually describes the data.

At minimum arr.dtype.subtype should never disagree with arr.left.dtype / arr.right.dtype.

Installed Versions

Details

INSTALLED VERSIONS
------------------
commit                : e68db09ecf6427d1b62e565bacf17f2e525a3032
python                : 3.13.11
python-bits           : 64
OS                    : Darwin
OS-release            : 23.3.0
pandas                : 3.0.5
numpy                 : 2.5.1
dateutil              : 2.9.0.post0

Also reproduced on main at 7986b42.