Edit polyhedral surfaces in place

As a developer using spatial-types,
I want to modify polyhedral-surface patches and their coordinates,
so that patch-based surfaces can be assembled and revised incrementally.

Context

Parent Epic: #38.

The scope is the layouts currently supported for PolyhedralSurface; this Story does not add new spatial types or coordinate layouts.

Depends on #39 for shared public contracts and explicit immutable naming, and on #43 for mutable polygon patches (which depends on #41 and #40).

Acceptance Criteria

• Mutable PolyhedralSurface is available in each currently supported layout with the family as the final constructor parameter, defaulting to Geometry.
• Consumers can add, insert, remove and replace patches, edit rings and points within patches and replace the full patch sequence.
• Patch order and supplied ordinates, including null values, are preserved.
• Mutation does not check face validity, adjacency, closure or manifold properties and does not implicitly repair neighbouring patches.
• Editing a point instance referenced by multiple patches changes every occurrence of that instance. Distinct points with equal coordinate values remain independent; shared-vertex detection, merging and synchronization are not performed.
• Supplied spatial components must be mutable: polygon patches, their rings and points. Immutable spatial components are rejected without implicit conversion. Coordinate-array input creates mutable descendants.
• Construction, insertion and replacement retain supplied component instances by reference without cloning; getters expose the same instances. Mutating a shared component is observable in every aggregate referencing it.
• Declared-SRID, spatial-reference and spatial-mode setters each accept a second boolean propagation parameter defaulting to true. With true, the change applies recursively to the receiver and all descendants; with false, only the receiver changes. No ordinates are recalculated.
• Every successful mutation returns the receiver with return type static for chaining.
• Indices start at zero at each nesting level. Insertion at the addressed sequence's count appends; access, replacement and removal require existing elements. Point addressing uses ring then point for polygons/triangles, and patch then ring then point for polyhedral surfaces.
• Failed addressing or technical input validation leaves the receiver and all referenced descendants unchanged.
• Family and declared-reference edits leave coordinates unchanged; spatial type and dimension remain fixed.
• Invalid addressing and technical input failures leave the receiver unchanged. Mutable PolyhedralSurface exposes 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 empty and incomplete surfaces, patch ordering, nested addressing, shared-vertex behavior and immutable-source isolation.
• Tests verify reference identity, immutable-component rejection, chained return identity, propagation enabled/disabled for each context setter, and failure atomicity across nested components.
• Story-specific public API documentation is updated.