feat: implement image cache

[drduhe]

Issue #, if available: n/a

Summary

Adds tile caching to the Cesium imagery pipeline so that previously tiled images load instantly without re-running the Docker-based tile generation process.

Problem

Every time an image was loaded into the Cesium viewer — even if it had already been tiled in a prior session — the full Docker pipeline was re-executed:

1. docker pull the ctb-quantized-mesh image
2. Spin up a new container
3. gdalwarp the image to EPSG:4326
4. Run calculate_extents.py to compute geographic bounds
5. Run ctb-tile to generate all tile PNGs

Only the raw S3 image download was cached; the expensive tiling steps were not.

Solution

• Per-image tile subdirectories: Tiles are now written to src/data/tiles/imagery/<imageName>/ instead of a flat shared directory. This prevents different images from overwriting each other's tiles and enables independent caching per image.
• Extents metadata file: After successful tile generation, the computed geographic extents are persisted to src/data/tiles/imagery/<imageName>/.extents.json.
• Cache check on load: Before launching any Docker operations, convertImageToCesium checks for a valid .extents.json and at least one zoom-level directory. On a cache hit, it skips the entire Docker pipeline and loads the existing tiles directly into Cesium.

Changes

• src/utils/cesiumImagery.ts
  • Added getExtentsMetadataPath() — resolves the .extents.json path for a tile cache directory
  • Added getCachedExtents() — validates cached metadata and tile directories; returns extents or null
  • Added saveCachedExtents() — writes extents JSON to disk after tile generation
  • Modified convertImageToCesium() — checks cache before running Docker; outputs tiles to per-image subdirectory; persists extents on completion

Checklist

Before you submit a pull request, please make sure you have the following:

• Code changes are compact and well-structured to facilitate easy review
• Changes are documented in the README.md and other relevant documentation pages
• PR title and description accurately reflect the changes and are detailed enough for historical tracking
• PR contains tests that cover all new code and the code has been manual tested
• All new dependencies are declared (if any), and no unnecessary libraries are added
• Performance impacts (if any) of the changes are evaluated and documented
• Security implications of the changes (if any) are reviewed and addressed
• I have read the Contributing Guidelines and agree to follow the Code of Conduct

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[devinglauner]

LGTM