For GeoJSON Z support, the tests should include mixed 2D and 3D coordinates in the same geometry collection if PostgreSQL/PostGIS allows it. That catches serializers that infer dimensionality from the first coordinate and then drop or reject later Z values. It would also be useful to assert round-tripping of Position arrays with Z but no M, so Z support does not accidentally imply M handling.

@hiSandog thanks for the review! Both scenarios are now covered, and digging into them turned up a related bug beyond just missing test coverage:

• Mixed 2D/3D within a MultiPoint/MultiLineString/MultiPolygon: FirstCoordinateHasZ decides the outer EWKB HasZ flag from the first member only, but nothing checked that the other members agreed. If they didn't, the writer emitted variably-sized member data while the reader kept assuming uniform sizing from the outer flag — silently corrupting the stream on read, exactly the failure mode you called out. Fixed by extending the existing "all-or-none" consistency check (already used for positions within one LineString/Polygon) up to these composite types, so a mismatch now throws a clear ArgumentException instead of producing bad EWKB.
• GeometryCollection: I initially assumed heterogeneous 2D/3D children already round-tripped fine, since the reader re-parses each child's own header. Turns out PostGIS itself rejects it server-side (Dimensions mismatch in lwcollection), confirmed directly against a live instance with plain WKT — independent of anything in this library. So GeometryCollection now gets the same client-side guard, and the new test asserts it throws rather than round-trips.
• Position with Z but no M: added Roundtrip_Z_without_M, confirming the altitude survives round-tripping on its own without implying/attaching M.

Pushed as a new commit on top of the branch.

Rebased to match main new file organisation