[P2-30] Reduce the public implementation surface and namespace TUI-only APIs

[phranck]

Problem

Target boundaries currently expose rendering and state implementation details as public API. Examples include FrameBuffer, RenderContext, RenderCache, StateStorage/StateBox, hydration types, child-provider infrastructure, and preference storage. TUI-specific APIs also sometimes occupy SwiftUI names or add incompatible overloads to them.

This increases compatibility burden, makes internals appear supported, and blocks safe refactoring.

Proposed solution

• Classify every exported symbol through the compatibility manifest.
• Move cross-target implementation contracts to Swift 6.0 package access where possible; use internal/SPI only with a documented need.
• Keep only intentional user-facing render primitives public.
• Rename or namespace TUI-specific types that collide with SwiftUI semantics and move terminal additions to clearly labeled modifiers/styles.
• Produce a reviewed source-breaking migration guide and deprecation path for a major release.

Acceptance criteria

• No type remains public solely because another package target or its tests need implementation access.
• RenderContext, caches, storage/hydration, and child traversal are absent from the normal public SDK unless individually justified.
• Every retained TUI-specific symbol has a clear name, use case, documentation, and no incompatible SwiftUI collision.
• Symbol-graph diff and migration notes make all source-breaking changes explicit.
• Module-isolated tests enforce dependency directions.
• Swift 6.0 macOS/Linux build, tests, lint, and DocC remain warning-free.

Dependencies

Depends on compatibility manifest #7, core/data-flow migration #17/#18, container/content migrations #24/#28, and module boundary tests #29.

Parallelization

Inventory can begin early. Actual access/name changes should follow each API family migration to avoid repeated source-breaking edits.

Commit structure

• Split this issue into small, thematic, independently revertible commits wherever the work can remain coherent.
• Every commit must build and keep its applicable tests/gates green. Do not commit an intentionally failing regression test; use local/known-issue characterization or land the test with the smallest fix.
• Keep characterization/fixtures, mechanical renames or moves, semantic changes, and documentation/migration updates separate when each step remains green.
• The issue boundary is not a commit boundary; multiple commits are expected for independently reversible changes.