fix: support SingleImageSatellite in POST /images download path

[caioarantes]

Problem

POST /images fails for every SingleImageSatellite (all DEMs, PolarisSoilTexture, WRBSoilClasses) with:

ImageCollection.__init__() missing 1 required positional argument: 'args'

download_multiple_images_async unconditionally calls satellite.imageCollection(ee_feature). Single-image classes implement image() instead, so the call lands on the AbstractSatellite stub, which returns ee.ImageCollection() with no arguments and raises.

Fix

Static datasets have no time dimension, so none of the collection-resolution machinery (date filtering, ZZ_USER_VALID_PIXELS thresholding, per-date chunking) applies. The images path now branches before building the collection expression and resolves a single getDownloadURL ZIP, saved as <shortName>.zip in the same cache dir, with the same retry/timeout policy as the collection path. The job result's dates list contains [shortName].

Two details worth flagging:

• scale=satellite.pixelSize is passed explicitly. Composited images (e.g. USGS3DEP1m, which does ee.ImageCollection(...).mosaic()) lose their source projection, and getDownloadURL then exports at the 1-degree default. Tested live: a ~415×445 m AOI returned a 667-byte raster without the scale argument, and a 558×446 px GeoTIFF at true 1 m with it.
• PolarisSoilTexture.__init__ called super().__init__ without parentheses — a no-op attribute access, so the base-class attributes were never initialized. Added the missing parens.

Validation

Run against a live deployment (built from main @ d81299e + this patch), through the full REST flow (POST /images → poll GET /jobs/{id} → GET /jobs/{id}/download):

Satellite	Result
USGS3DEP1m	558×446 px GeoTIFF @ 1 m over ~415×445 m AOI
PolarisSoilTexture	20×16 px @ 30 m, all four bands (clay/sand/silt/usda_soil_class)
NAIP (regression)	unchanged, still working

🤖 Generated with Claude Code