Add Sentinel-1D support

[dbekaert]

Summary

Adds Sentinel-1D support across the pipeline: AUX_CAL downloads, DAAC metadata schema, and SLC validation.

Changes

AUX_CAL downloads (localize_aux_cal.py)

• S1A/S1B: continue using ASF CloudFront bundles as baseline
• All missions (S1A–D): supplement from ESA SAR-MPC API (https://sar-mpc.eu/api/v1/) to pick up newer files and S1C/S1D entries
• Handles pagination and skip-if-exists caching

SLC validation (localize_slc.py)

• Added S1D_MIN_DATE (2026-04-17) placeholder to reject uncalibrated S1D acquisitions, mirroring the existing S1C_MIN_DATE check
• Updated error messages to include S1D

Metadata (daac_ingest_schema.json)

• Added Sentinel-1D to platform enum

Tests (test_localize_slc.py)

• Added test for S1D minimum date validation
• Updated error match patterns

Upstream dependencies

• s1_orbits: Already supports S1D via S1[ABCD] regex — no changes needed
• ISCE2: Requires S1D track number offset (42) in Sentinel1.py — see isce2#28123 (pending merge)

Notes

• S1D_MIN_DATE is a placeholder — update once S1D calibration is officially confirmed by ESA
• S1D orbit offset (42) is based on the commissioning orbit and may change when S1D moves to its final orbit (expected summer 2026)

[dbekaert]

ASF/DAAC Ingest Coordination
@asjohnston-asf — heads up on a potential ingest concern.

This PR adds "Sentinel-1D" (and "Sentinel-1C") to the platform enum in the producer-side DAAC ingest schema (daac_ingest_schema.json). When S1D products are generated, the JSON metadata will include "platform": ["Sentinel-1D", ...].

Question: Does ASF's receiving-side ingest validation / CMR collection configuration already support Sentinel-1D as a valid platform value? If not, S1D products would pass our local schema validation but could fail on ingest.

Specifically wondering about:

Server-side schema validation of the platform field
CMR collection metadata for the GUNW product suite
Any downstream search/discovery services that filter by platform

[dbekaert]

@cmarshak Can you keep an eye on this? We should do a test when the dependencies are ready.

[jhkennedy]

It appears ISCE2 is dead; see:
conda-forge/isce2-feedstock#86

Edit: looks like issues were just "temporarily" disabled due to spam:
isce-framework/isce2#28120

I have an open PR to the conda-forge recipe that will enable S1D support by patching the build (dirty):

So, if that PR is merged, DockerizedTopsApp could process S1D by changing the isce2 dependency in the environment file to:

- "isce2[version='==2.6.4', build_number='>=3']"

@cmarshak do you know the status of ISCE2? Any chance we could get S1D support merged and released?

[cmarshak]

I will have to ask - I have no idea. I don't think there is any active support of ISCE2.

[cmarshak]

I am manually adding in the file that @jacquelynsmale has in PR to ISCE2. I am hoping that this would be a temporary fix and then we can move forward more stably once the S1D pattern is officially released in ISCE2.

[cmarshak]

I am fine merging this as long as we agree to delete these lines once ISCE2 is released (would be separate PR):

DockerizedTopsApp/Dockerfile

Lines 36 to 39 in 5dc0498

	# TODO: Remove this when ISCE2 releases S1D Fixes
	RUN TARGET_DIR=$(conda run -n topsapp_env python -c "import isce; import os; print(os.path.dirname(isce.__file__))") && \
	curl -sSL -o "${TARGET_DIR}/components/isceobj/Sensor/TOPS/Sentinel1.py" \
	https://raw.githubusercontent.com/isce-framework/isce2/7bd57893ed9ae2d7ac0f7dd0e06625e337b0b993/components/isceobj/Sensor/TOPS/Sentinel1.py

[cmarshak]

Also, my understanding in talking with @mgovorcin is that S1D is "officially" calibrated, but the data doesn't look quite right yet.