Define the public and internal API boundary

As a developer using spatial-types,
I want the library's supported public API and internal implementation symbols to be clearly identified,
so that I can find and rely on the intended consumer-facing contracts without mistaking implementation details for supported APIs.

Context

PHP visibility does not by itself communicate whether a symbol is intended for library consumers. The repository contains consumer-facing types and interfaces alongside abstract base classes and implementation helpers that must remain technically accessible to collaborate across classes.

The Product Owner has reviewed the repository by explicit groups and approved these classifications:

• All abstract base classes are internal.
• Shared implementation mechanisms, including traits, guards, hydrators and supporting collections, are internal.
• The 84 type-specific factories are public. SpatialFactory is public for its documented static mode-selection methods; its constructor and aggregate-hydration methods are internal. FromIndexedArrayFactory and the factory pipeline helpers are internal.
• All interfaces are public.
• Concrete spatial types, the public builder, implementation-status query, exceptions, SpatialReference, and Value\Coordinates are public. Boundary\PolygonBoundary and Collection\LineStringCollection are internal.
• The helpers currently under Factory\Internal are to be moved under Internal\Internal.

Internal status identifies a symbol as outside the supported public API. It does not mean that maintainers may change or remove it arbitrarily between minor releases. Such changes require deliberate impact assessment and clear documentation; this Story does not establish a separate automatic compatibility guarantee for internal symbols.

Story #27 reviews and stabilizes all public contracts for the spatial-types 1.0.0 baseline. This Story establishes the agreed classifications and discoverable boundary that review depends on. It must be completed before the normative review in Story #26 proceeds, so that the scope of public behavior being reviewed is explicit.

Acceptance Criteria

• Every PHP class, interface, trait and enum in lib/ is accounted for by the approved classification groups, with any unclassified exception explicitly identified.
• Public symbols are identifiable to consumers from repository documentation or another authoritative, discoverable inventory.
• Every accessible internal symbol is explicitly marked @internal; every symbol under an Internal namespace is also marked @internal.
• All abstract base classes and shared implementation mechanisms are classified as internal, while all interfaces and approved concrete consumer-facing types remain public.
• The 84 type-specific factories remain public; only the documented static mode-selection methods of SpatialFactory are identified as its public supported API.
• Factory\Internal helpers are relocated to Internal\Internal, and internal imports and references are updated accordingly.
• Documentation states that internal status excludes a symbol from the supported public API contract but does not authorize arbitrary changes between minor releases; internal changes receive deliberate impact assessment and clear documentation.
• The public/internal classification and discoverability do not claim a new compatibility guarantee or change the project's existing backward-compatibility policy.

Definition of Done

The project's common Definition of Done applies. Complete this checklist with any additional verification required specifically by this story.

• composer test-local passes.
• composer quality passes.
• Tests or an equivalent automated check verify the internal-marker and namespace rules for the resulting symbol inventory.
• Public and internal API documentation reflects the approved classifications and internal evolution statement.