fix(mysql, mariadb): persist the SRID of GeoJSON geometries - #18525

Pull Request Checklist

• Have you added new tests to prevent regressions?
• If a documentation update is necessary, have you opened a PR to the documentation repository? Not needed.
• Did you update the typescript typings accordingly (if applicable)? No typing changes.
• Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
• Does the name of your PR follow our conventions?

Description of Changes

On MySQL and MariaDB, the crs of a GeoJSON value was lost:

• Write: the value was converted to WKT without its SRID, so it was stored with SRID 0, or the column's SRID if one was declared.
• Read: MySQL discarded the 4-byte SRID prefix of the stored value, and MariaDB used the driver's parsed geometry, which drops it too. So crs never came back from the database.

The "works with crs field" tests only checked the instance returned by create(), which on these dialects just echoes the input. That hid the bug; it was found during the test audit in #18520. Postgres was not affected.

This PR:

• Write: values with a named crs are written with ST_GeomFromText(wkt, srid). Without a crs, the column's SRID is used as before, and if neither is set the call has no SRID.
• Read: the SRID is read from the 4-byte prefix and returned as crs: { type: 'name', properties: { name: 'EPSG:<srid>' } }, the same shape postgres returns.
• Axis order (MySQL): MySQL reads WKT in the axis order of the spatial reference system, which is latitude-longitude for geographic systems such as EPSG:4326. GeoJSON is always longitude-latitude, so we now pass 'axis-order=long-lat' (MySQL 8.0.12+) whenever an SRID is set. This also fixes coordinates that were swapped, or rejected as out of range, on columns declared with an SRID such as GEOMETRY('POINT', 4326). MariaDB has no such option and doesn't swap axes.
• Inline values: escaping used by bulkCreate and where wrapped the ST_GeomFromText(...) call in a string literal, so those failed. They now produce the function call.
• MariaDB NULLs: a NULL in a typed column such as POINT is now read as null instead of { type: 'Point' }.

Tests:

• The 8 "works with crs field" integration tests now reload the row from the database.
• New integration tests cover: a value without crs, crs kept through update and bulkCreate, a where on a value with crs, an SRID unknown to the database, NULL, and a column declared with SRID 4326 (axis order, and falling back to the column's SRID).
• New unit tests cover the generated SQL on mysql and mariadb.

Verified on MySQL 8.4, MariaDB 11.6 and PostGIS 3.6.

Postgres has the same inline-escaping bug for bulkCreate and where ("parse error - invalid geometry"). Those new tests skip postgres with a TODO, to be fixed in a separate PR.

List of Breaking Changes

None in the API, but stored data and query results change on MySQL/MariaDB:

• Geometries written with a crs are now stored with that SRID instead of 0. On MySQL, functions like ST_Distance then work on the ellipsoid (metres instead of degrees), and raw SQL that compares old SRID-0 rows with new rows can fail on the SRID mismatch.
• A crs that differs from the column's SRID, or is unknown to MySQL, is now rejected by the database instead of being silently dropped. Postgres already behaved this way.
• New writes to columns declared with a geographic SRID are no longer axis-swapped on MySQL. Rows written before this fix keep their swapped coordinates.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • MySQL and MariaDB now preserve coordinate reference systems (CRS) when reading and writing geometry values, including across reloads, updates, saves, and bulk creation.
  • Geometry values with a valid named CRS use its SRID; values without one can use the column’s SRID. Unsupported CRS names and invalid SRIDs are rejected.
  • MySQL geometry handling specifies longitude–latitude axis order when an SRID is present, helping preserve coordinate ordering.
  • Geometry columns correctly reload null values, and missing or empty geometry data returns null.