fix ISO bbox antimeridian handling for MDTranslator spatial output

[FuhuXia]

The ticket is the result of Issue #6031 investigation. It is found that MDTranslator returns ISO bounding boxes as a comma-separated spatial string, not GeoJSON.

For the Census concity record, the value is:

  179.77847,-14.548699,-179.146711,71.387815

translate_spatial() passes the raw string to validate_geojson(), then falls back to munge_spatial(). munge_spatial() converts the bbox to an unsplit GeoJSON Polygon and returns it directly, so the generated geometry is not revalidated and spatial_wrap_around_meridian() is not triggered.

As a result, antimeridian-crossing ISO bboxes are stored/indexed as invalid or misleading unsplit Polygons instead of corrected wrapped MultiPolygons.

How to reproduce

harvest a record with spatial = "179.77847,-14.548699,-179.146711,71.387815"

Expected behavior

A valid MultiPolygon split at the antimeridian before being stored in translated_spatial and indexed into OpenSearch.

  {
    "type": "MultiPolygon",
    "coordinates": [
      [[[179.77847, -14.548699], [179.77847, 71.387815], [180.0, 71.387815], [180.0, -14.548699],
      [179.77847, -14.548699]]],
      [[[-180.0, 71.387815], [-179.146711, 71.387815], [-179.146711, -14.548699], [-180.0,
      -14.548699], [-180.0, 71.387815]]]
    ]
  }

Actual behavior

The bbox is converted to an unsplit GeoJSON Polygon:

  {
    "type": "Polygon",
    "coordinates": [[[179.77847,-14.548699],[179.77847,71.387815],[-179.146711,71.387815],
    [-179.146711,-14.548699],[179.77847,-14.548699]]]
  }

[rshewitt]

up until now there hasn't been an issue with what mdtranslator provides as a spatial value so i'm hesitant to change that. i think the path of least change would be to run munge_spatial before translate_spatial_to_geojson for ISO records so the anti-meridian logic is executed.