ERA5 loader silently clamps out-of-range timestamps to nearest boundary

[fjsuarez]

Problem

The ERA5 field closures (wind, wave) use jax.scipy.ndimage.map_coordinates with mode="nearest". When t exceeds the temporal extent of the loaded NetCDF file, the query is silently clamped to the last available timestep.

Example: A route departing Dec 28 2024 with a 10-day crossing needs weather data into Jan 7 2025. If only 2024 data is loaded, segments arriving in 2025 silently use Dec 31 2024 18:00 weather — frozen in time, no error, no warning.

Impact

• Optimization produces routes that ignore actual weather conditions for the later portion of the voyage
• Performance/cost calculations are based on stale data
• The user has no indication this is happening

Proposed solution

1. Download script: Accept a date range (not just a single year) so overlapping data can be fetched:

   uv run scripts/download_era5.py --start 2024-12-01 --end 2025-02-01

2. Loader: Support loading and concatenating multiple NetCDF files along the time axis
3. Boundary warning: Log a warning (or raise) when t exceeds the dataset's temporal range

Workaround

For now, download a second year and concatenate manually with xarray, or ensure departures are early enough that the full voyage fits within the downloaded year.

[fjsuarez]

Fix: download January 2025 ERA5 data

Impact

ERA5 data covers 2024-01-01T00:00 → 2024-12-31T18:00. The loader uses mode="nearest", silently repeating the last time step for voyages extending into January 2025.

• Atlantic (354h = 14.75 days): departures Dec 18–31 affected → 13 departures
• Pacific (583h = 24.29 days): departures Dec 8–31 affected → 23 departures

These voyages currently optimize against frozen weather for the final portion of the passage.

Proposed fix

1. Extend download_cds.py and download_gcs.py to fetch January 2025 data
2. Concatenate with the 2024 files (or extend the existing NetCDFs)
3. Update the loader to handle the extended time range seamlessly — no API change needed since departure_time offset is computed from the first record
4. Re-run the affected departures

This fully resolves the clamping for all 366 SWOPP3 departures.