Fix isort drift in two geotiff files

[brendancol]

Closes #3588

• Runs isort over the two geotiff files that drifted from the setup.cfg config (line_length=100): xrspatial/geotiff/_writers/eager.py and xrspatial/geotiff/tests/write/test_symbology_sidecar_3537.py. Both hunks came in with the to_geotiff: write best-practice symbology sidecars for continuous rasters (QGIS color ramp) #3537 symbology work.
• Formatting only: a blank line after two inline imports, and one parenthesized import joined to a single line. flake8 was already clean and stays clean.
• Also updates the style-sweep state CSV row for geotiff (found via the Cat 4 import-ordering check; Cat 1/2/3/5 were clean).

No behavioral change, so backend coverage is unaffected (numpy / cupy / dask+numpy / dask+cupy all untouched).

Test plan:

• flake8 xrspatial/geotiff/ clean
• isort --check-only xrspatial/geotiff/ clean
• pytest xrspatial/geotiff/tests/write/test_symbology_sidecar_3537.py passes (25 tests, CUDA available locally)

[brendancol]

PR Review: Fix isort drift in two geotiff files

Formatting-only diff: a blank line after two inline imports and one parenthesized import joined to a single line (88 chars, under the 100-col limit). I verified both files parse to an AST identical to main, so there is no behavioral change by construction. flake8 and isort pass on the whole subpackage after the change, and the 25 symbology sidecar tests pass locally with CUDA.

The state-CSV change touches only the geotiff row.

Blockers

None.

Suggestions

None.

Nits

None.

What looks good

• The fix is the raw isort output for the two files, nothing hand-edited on top.
• Issue #3588 has the reproduction and traces the drift to the #3537 symbology work.

Most of the standard checklist (backend parity, NaN handling, dask depth, benchmarks, docs) does not apply to a whitespace change, so those sections were skipped.