Add max_z_error parameter for lossy LERC compression

[brendancol]

Closes #1510.

LERC takes a maxZErr argument: 0.0 is lossless, larger values let the encoder approximate within that bound. The codec wrapper in _compression.py already accepted it, but every writer above it hard-coded 0.0, so there was no way to ask for a lossy LERC write from the public API.

to_geotiff now takes max_z_error: float = 0.0 and threads it through the eager write, the dask streaming write, the VRT path, the COG/overview path, and every helper that calls lerc_compress.

Validation runs up front in to_geotiff:

• max_z_error < 0 raises ValueError.
• max_z_error != 0 with any codec other than 'lerc' raises ValueError, so a non-zero budget never gets silently dropped.
• max_z_error != 0 on the GPU writer raises ValueError. nvCOMP has no LERC backend.

Tests in a new test_lerc_max_z_error.py cover: bit-exact lossless round-trip at 0.0; 0.05 on a smooth float32 surface yields a strictly smaller file with abs(decoded - original) <= 0.05 everywhere; dask streaming with a non-zero budget; negative values and non-LERC codecs raising ValueError; and max_z_error=0.0 with zstd still working (the default must not break other codecs).

Test plan

• pytest xrspatial/geotiff/tests/test_lerc_max_z_error.py -v (6 passed)
• pytest xrspatial/geotiff/tests/test_lerc.py -v (13 passed)
• pytest xrspatial/geotiff/tests/ (673 passed, 4 skipped). Three matplotlib TestPalette recursion errors reproduce on origin/main and are unrelated.