Add early spatial_extent validation for common user input errors in load_collection//validation

[Copilot]

spatial_extent mistakes currently produce either late-stage backend errors or unclear failures. This PR adds early, explicit validation for common malformed extents so both execution and /validation return actionable ProcessParameterInvalid messages.

• Input shape/type validation

  • Require spatial_extent to be a mapping object (reject list-style extents like [1,2,3,4] at driver level).
  • Validate west/south/east/north as numeric scalar values (reject list/invalid types and booleans).

• Extent consistency checks

  • Enforce axis ordering with clear messages:
    • west < east
    • south < north
  • Converts previously obscure downstream extent failures into deterministic input errors.

• CRS-missing coordinate sanity check

  • When crs is omitted (defaulting to EPSG:4326), reject coordinates outside valid lon/lat bounds.
  • This catches common UTM/projected-coordinate input without CRS and asks users to specify CRS explicitly.

• Validation endpoint coverage

  • Added focused /validation tests for:
    • non-dict spatial_extent
    • non-numeric coordinate values
    • swapped west/east
    • swapped south/north
    • projected-like coordinates without crs

Example of newly caught input:

"spatial_extent": {
  "west": 4329317.717132108,
  "east": 4330615.2810456185,
  "north": 3005295.0854642093,
  "south": 3003997.791438847
}

This now fails early with a clear message that coordinates are outside EPSG:4326 range and crs should be provided.