In open_zarr, decode_timedelta does not behave as documented

What happened?

The documentation states that, for open_zarr, if decode_timedelta is None it will take the value of decode_times which is True by default. That isn't the behaviour I'm seeing, timedeltas are not being decoded.

What did you expect to happen?

I expected timedeltas to be decoded.

Minimal Complete Verifiable Example

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "xarray[complete]@git+https://github.com/pydata/xarray.git@main",
# ]
# ///
#
# This script automatically imports the development branch of xarray to check for issues.
# Please delete this header if you have _not_ tested this script with `uv run`!

import xarray as xr
xr.show_versions()
# your reproducer code ...
xr.open_zarr('gs://weatherbench2/datasets/hres/2016-2022-0012-1440x721.zarr',storage_options={"token": "anon"}, decode_times=True, decode_timedelta=None)

Steps to reproduce

In a conda environment with xarray 2026.7.0, zarr 3.3.0, fsspec 2026.6.0 and gcsfs 2026.7.0, run the following code:
xr.open_zarr('gs://weatherbench2/datasets/hres/2016-2022-0012-1440x721.zarr',storage_options={"token": "anon"}, decode_times=True, decode_timedelta=None)

It returns a dataset with the timedeltas not decoded.

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.Dataset> Size: 87TB
Dimensions:                   (time: 5134, prediction_timedelta: 41,
                               latitude: 721, longitude: 1440, level: 13)
Coordinates:
  * time                      (time) datetime64[ns] 41kB 2016-01-01 ... 2023-...
  * prediction_timedelta      (prediction_timedelta) int64 328B 0 6 ... 234 240
  * latitude                  (latitude) float32 3kB -90.0 -89.75 ... 89.75 90.0
  * longitude                 (longitude) float32 6kB 0.0 0.25 ... 359.5 359.8
  * level                     (level) int32 52B 50 100 150 200 ... 850 925 1000
Data variables: (12/16)
    10m_u_component_of_wind   (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    10m_v_component_of_wind   (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    10m_wind_speed            (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    2m_temperature            (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    geopotential              (time, prediction_timedelta, level, latitude, longitude) float32 11TB ...
    mean_sea_level_pressure   (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    ...                        ...
    total_precipitation_24hr  (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    total_precipitation_6hr   (time, prediction_timedelta, latitude, longitude) float32 874GB ...
    u_component_of_wind       (time, prediction_timedelta, level, latitude, longitude) float32 11TB ...
    v_component_of_wind       (time, prediction_timedelta, level, latitude, longitude) float32 11TB ...
    vertical_velocity         (time, prediction_timedelta, level, latitude, longitude) float32 11TB ...
    wind_speed                (time, prediction_timedelta, level, latitude, longitude) float32 11TB ...

Anything else we need to know?

No response

Environment

Start at the open_zarr entry point and compare its decode_timedelta handling with the documented decode_times behavior. Run the provided xr.open_zarr reproducer using the stated options, then verify that the prediction_timedelta coordinate is decoded when decode_timedelta is None and add or update coverage for that case.