Calling `.isel()` on a timezone-aware dimension/index causes it to lose timezone information

What happened?

With a Dataset/DataArray containing a time dimension whose index uses the datetime64[ns, utc] (timezone-aware) dtype, if one calls .isel() to slice say the first element in this dimension, the time coordinate in the resulting Dataset/DataArray will have reverted to datetime64[ns] (i.e. timezone-naive).

What did you expect to happen?

Resulting Dataset/DataArray should retain the timezone-awareness on the coordinate of the sliced time dimension/index and still use datetime64[ns, utc] dtype

Minimal Complete Verifiable Example

import numpy as np
import pandas as pd
import xarray as xr

mydata = xr.DataArray(
    data=np.array([
        [0, 1, 2, 3],
        [4, 5, 6, 7],
        [8, 9, 10, 11]
    ]),
    coords={
        "category": ["A", "B", "C"],
        "time": pd.to_datetime([
            "2024-08-02T11:00:00+00:00",
            "2024-08-02T12:00:00+00:00",
            "2024-08-02T13:00:00+00:00",
            "2024-08-02T14:00:00+00:00"
        ])
    },
    name="volume"
)
print(mydata)
print("---------------------------")
print(f"time index dtype before calling `.isel()`: {mydata.indexes['time'].dtype}")
print(f"time coord dtype before calling `.isel()`: {mydata.coords['time'].dtype}")
print("---------------------------")
# The following will slice the zeroth index in the time dimension - the time index will cease to exist but the corresponding coordinate will remain
subset = mydata.isel(time=0, drop=False)
print("---------------------------")
print(subset)
print("---------------------------")
print(f"time coord dtype after  calling `.isel()`: {subset.coords['time'].dtype}")

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.
• Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

<xarray.DataArray 'volume' (category: 3, time: 4)> Size: 96B
array([[ 0,  1,  2,  3],
       [ 4,  5,  6,  7],
       [ 8,  9, 10, 11]])
Coordinates:
  * category  (category) <U1 12B 'A' 'B' 'C'
  * time      (time) object 32B 1722596400000000000 ... 1722607200000000000
---------------------------
time index dtype before calling `.isel()`: datetime64[ns, UTC]
time coord dtype before calling `.isel()`: object
---------------------------
---------------------------
<xarray.DataArray 'volume' (category: 3)> Size: 24B
array([0, 4, 8])
Coordinates:
  * category  (category) <U1 12B 'A' 'B' 'C'
    time      datetime64[ns] 8B 2024-08-02T11:00:00
---------------------------
time coord dtype after  calling `.isel()`: datetime64[ns]

Anything else we need to know?

Tested with version 2024.3.0 and also 2024.7.0.

Similar to #6416

Environment

Start at the .isel(time=0, drop=False) entry point and run the minimal example from the issue to reproduce the dtype change. Trace how the sliced time coordinate is constructed; done means the resulting coordinate remains timezone-aware with datetime64[ns, UTC] rather than becoming timezone-naive.