Edit multi-objects and spatial collections in place

As a developer using spatial-types,
I want to modify members of multi-objects and spatial collections,
so that groups of spatial values can evolve without replacing the aggregate instance.

Context

Parent Epic: #38.

This covers mutable MultiPoint, MultiLineString, MultiPolygon and SpatialCollection. SpatialCollection is the family-independent mutable counterpart of GeometryCollectionImmutable/GeographyCollectionImmutable; for example, its XY class is Types/Dimension2/SpatialCollection.php.

Depends on #39 for shared public contracts and explicit immutable naming, and on #40, #41 and #43 for mutable points, lines and polygons. Full SpatialCollection coverage also depends on #42 and #44 for compound curves and polyhedral surfaces.

Acceptance Criteria

• Mutable MultiPoint, MultiLineString, MultiPolygon and SpatialCollection are available in every currently supported layout. SpatialCollection remains the same class and instance when its mode changes between Geometry and Geography.
• Their final constructor parameter selects the family and defaults to Geometry.
• Consumers can append, insert, remove and replace members and replace complete ordered membership.
• MultiPoint accepts mutable points, MultiLineString accepts mutable line strings, and MultiPolygon accepts mutable polygons. SpatialCollection accepts the supported mutable spatial types through MutableSpatialInterface, including nested mutable collections.
• Construction and member-mutation methods reject immutable spatial members without implicit conversion or cloning. Supported coordinate-array input creates mutable descendants.
• Empty members, incomplete ordinates and geometrically invalid representable data are preserved without automatic validation.
• Construction, append, insertion and replacement retain supplied mutable members by reference, without copying. Member getters expose those same instances; edits to a shared member or descendant are visible in every aggregate referencing it.
• Member indices start at zero. Insertion at the member count appends; indexed access, replacement and removal require existing members.
• All successful mutation methods return the receiver with return type static for chaining.
• Declared-SRID, spatial-reference and spatial-mode setters each accept a second boolean propagation parameter defaulting to true. With true, changes propagate recursively through members to all descendants, including points; with false, only the receiver changes. Coordinates are never recalculated and geometries are not repaired.
• Propagation updates the existing shared instances, so the changes are also observable through other references to those instances.
• Spatial type and dimension remain fixed. Invalid addressing or technical input failures leave the receiver and all referenced descendants unchanged. Mutable multi-objects and SpatialCollection expose no with… methods.
• Mutable types implement the applicable MutableInterface and MutableSpatialInterface contracts, expose no with… methods and have no dimension setter.
• Mutable spatial classes reside directly in their dimension namespace, alongside Geometry and Geography; spatial mode is instance state, not fixed by a family namespace.
• Declared-SRID/reference and spatial-mode setters update the same instance without recalculating coordinates; the final constructor family parameter defaults to SpatialModelEnum::GEOMETRY.

Constraints

• Apply Story: Preserve immutable types under explicit names and shared contracts #39: concrete immutable classes are final, immutable aggregates reject mutable components without conversion, common interfaces are read-only, and with… methods belong exclusively to immutable variants. Do not add deprecated aliases for renamed classes.
• Coordinate layout and spatial type remain fixed. Geometric validity is delegated to explicit spatial-validator use; do not introduce automatic validation, repair, reprojection or dimension conversion. Changes to declared family or reference preserve coordinates. Preserve the representable states established by Story: Allow partially null point ordinates #36.
• Follow the naming and namespace layout defined by Epic: Support mutable and immutable spatial objects #38. Preserve the distinction between technical representation and normative geometric validity under ISO/IEC 13249-3 and applicable OGC specifications.

Definition of Done

The project's common Definition of Done applies.

• composer test-local passes.
• composer quality passes.
• Tests cover all four collection kinds, all supported member types, empty membership, immutable-input rejection, reference identity, shared members and descendants, nested collections, chaining, zero-based indexing and failure atomicity. Both propagation settings are exercised for each context setter.
• Story-specific public API documentation is updated.