cql2-json: {"bbox": ...} literals scramble axes through values.Envelope field order

`parsers/cql2_json/parser.py` builds a BBox literal with `values.Envelope(*node["bbox"])`:

https://github.com/geopython/pygeofilter/blob/master/pygeofilter/parsers/cql2_json/parser.py#L78-L79

A GeoJSON-order bbox `[minx, miny, maxx, maxy]` therefore lands in `Envelope(x1, x2, y1, y2)` as `x1=minx, x2=miny, y1=maxx, y2=maxy`.

Since #147, the convention used by the cql2-text parser and the SQLAlchemy backend is `x1=minx, x2=maxx, y1=miny, y2=maxy` (the backend's envelope handler passes `[x1, y1, x2, y2]` to `parse_bbox`, and #147's test expects `Envelope(-180, 180, -90, 90)` for the global box). Through that convention the JSON construction mixes longitudes and latitudes.

Concrete effect via the SQLAlchemy backend: for `{"bbox": [-74.1, 40.5, -73.9, 41.0]}` (a ~20 km box over New York) the backend's envelope handler hands `[x1, y1, x2, y2] = [-74.1, -73.9, 40.5, 41.0]` to `parse_bbox`, which renders a polygon spanning x from -74.1 to 40.5 and y from -73.9 to 41.0 (roughly 114 by 115 degrees), so `S_INTERSECTS` silently matches a large part of the hemisphere rather than erroring.

Expected: `Envelope(minx, maxx, miny, maxy)`, i.e. `values.Envelope(b[0], b[2], b[1], b[3])`.

Found while wiring pygeofilter 0.4.0 into an OGC API Features Part 3 endpoint; we currently rewrite `{"bbox": ...}` nodes to explicit GeoJSON Polygons before parsing to avoid the scramble.

Start in parsers/cql2_json/parser.py at the BBox construction on lines 78-79, then compare its field ordering with the cql2-text parser and the SQLAlchemy backend's envelope handler. Verify the example New York bbox through parse_bbox; done means GeoJSON [minx, miny, maxx, maxy] becomes Envelope(minx, maxx, miny, maxy) without axis scrambling.

Written by the indexing model from the issue text.