Geospatial feature comprehension: parse failure when `/map/queries` response is top-level array instead of `GeospatialMapQueryReply` object

[ZachHubbs]

Observed behavior

In the InterUSS monitoring geospatial scenario, the harness failed while parsing the USS response to POST /geospatial_map/map/queries.

The failing run reported (log.txt attached to issue):
Response to geospatial map query could not be parsed: Expected to find dictionary data to populate GeospatialMapQueryReply object but instead found list type

From our side, the response body at that time was a top-level JSON array, e.g.:

[
  {
    "features_selection_outcome": "PRESENT"
  }
]

instead of an object matching GeospatialMapQueryReply with a results field.

After updating our response to:

{
  "results": [
    {
      "features_selection_outcome": "Present"
    }
  ]
}

the scenario no longer throws parsing errors .

Test check
Scenario: Geospatial feature comprehension
Failed check: Geospatial query succeeded
Failure detail: parse error when converting response into GeospatialMapQueryReply (list received where dict/object expected).

Difference from expected behavior
The harness behavior appears consistent with the spec (QueryGeospatialMap expects GeospatialMapQueryReply object), and our original response was non-compliant. The issue here is primarily to document this failure mode clearly for others, because the parse exception is easy to hit if a USS returns a top-level array and/or enum casing that does not match spec values.

Expected behavior (now confirmed): a GeospatialMapQueryReply object with results containing check results, using spec enum values like Present/Absent/UnsupportedFilter/Error.

log.txt