geotiff: (y, x, time) DataArrays silently treated as multiband rasters

[brendancol]

Describe the bug

xrspatial/geotiff/_validation.py:46 accepts any 3D writer input whose first two dims are spatial, regardless of the third dim name. The CPU writer (_writers/eager.py:627) and GPU writer (_writers/gpu.py:335) both treat that trailing axis as bands. Temporal stacks with dims=('y','x','time') are written as a 3-band TIFF without warning.

('time','y','x') is rejected (the existing _validate_3d_writer_dims catches it), so the failure mode is asymmetric.

Reproduction

import numpy as np, xarray as xr, tempfile
from xrspatial.geotiff import to_geotiff

da = xr.DataArray(np.zeros((4,4,3), dtype=np.float32),
                  coords={'y': np.arange(4), 'x': np.arange(4), 'time': np.arange(3)},
                  dims=('y','x','time'))
with tempfile.NamedTemporaryFile(suffix='.tif') as f:
    to_geotiff(da, f.name)  # writes 3-band TIFF, no error

Expected behavior

When the trailing dim of a 3D input is a known temporal name (e.g. time, t, date, datetime), to_geotiff should refuse with a clear error. The caller can reshape, rename the dim, or pick a single time slice explicitly. The fallback that permits (y, x, <unknown>) for raw numpy callers should remain in place for genuinely unknown dim names.

Additional context

This is the same silent-corruption class as issue #1812 (which added the original _validate_3d_writer_dims), extended to the case where the third dim is a known non-band name rather than an unknown one. The fix lives in _validate_3d_writer_dims so all writer entry points pick it up.