docs(v0.9): split renderer guide into core SDK and UI adapter guides

[jacobsimionato]

Description of Changes

This PR refactors the specification/v0_9/docs/renderer_guide.md into two distinct, highly-focused implementation manuals:

1. core_sdk_implementation_guide.md: Details the framework-agnostic Data Layer (State Models, DataModel, MessageProcessor, logic evaluation, and capability generation). It includes a rigorous, test-driven 7-Phase Implementation Workflow specifically targeted at building the underlying data primitives.
2. ui_framework_adapter_implementation_guide.md: Details the View Layer (Rendering loop, buildChild recursion, Component Implementation strategies, and framework-specific lifecycle management). It explicitly requires the developer to either adopt or build the Core SDK in Phase 1 before building the native UI bindings.

The original renderer_guide.md has been safely deleted.

Rationale

The previous renderer guide conflated the framework-agnostic protocol mechanics (which can be written once per language) with the framework-specific rendering mechanics (which are needed for every UI framework). Splitting the documentation:

• Clarifies the boundaries between the Core SDK and the Framework Adapter.
• Allows developers to focus exclusively on their layer of concern (e.g. building a React adapter on top of the existing TS Web Core, without having to read about JSON pointer resolution).
• Better supports AI agents and developers who are porting A2UI to new languages, by providing targeted, phase-by-phase implementation instructions with specific unit testing goals.

Testing/Running Instructions

Reviewers can read the new markdown files locally:

1. cat specification/v0_9/docs/core_sdk_implementation_guide.md
2. cat specification/v0_9/docs/ui_framework_adapter_implementation_guide.md

Ensure that all technical details and requirements from the original renderer_guide.md have been preserved and properly distributed. You can also verify that there are no broken links in the mkdocs.yaml or a2ui_protocol.md (these were checked during the split).

[gemini-code-assist]

Code Review

This pull request restructures the A2UI documentation by splitting the previous unified architecture guide into two specialized documents: the Core SDK Implementation Guide and the UI Framework Adapter Implementation Guide. This separation distinguishes framework-agnostic state management from framework-specific rendering logic. Review feedback highlights the need for more precise language regarding array index handling in non-JavaScript environments, stricter boolean type coercion to avoid silent validation errors, and the restoration of critical lifecycle rules and framework-specific pseudo-code examples that were lost during the refactoring.

[gemini-code-assist]

The term "empties the index" is specific to JavaScript's sparse arrays. In languages like Java, Kotlin, or Swift, this concept is not native. It would be clearer to specify that the value at the index is set to null or a language-specific equivalent while maintaining the array's length.

Suggested change

	4. **Undefined Handling**: Setting an object key to `undefined` removes it. Setting an array index to `undefined` preserves length but empties the index.
	4. **Undefined Handling**: Setting an object key to undefined removes it. Setting an array index to undefined preserves length but sets the value at that index to null (or the language's equivalent).

[gemini-code-assist]

Coercing any string other than "true" or "false" to false is potentially dangerous as it can hide typos or logic errors in the protocol messages. It is safer to strictly validate boolean strings or follow a standard truthiness model.

Suggested change

	| `String` ("true", "false") | `Boolean` | `true` or `false` (case-insensitive). Any other string maps to `false`. |
	| String ("true", "false") | Boolean | "true" maps to true, "false" maps to false (case-insensitive). Other strings SHOULD result in a validation error. |

[gemini-code-assist]

The normative requirements for surface and component lifecycles (e.g., handling duplicate surface IDs or component type changes) were present in the original renderer_guide.md but are missing from the descriptive text here. These should be explicitly stated as implementation requirements for the MessageProcessor.

Suggested change

	The "Controller" that accepts the raw stream, parses messages, and mutates models.
	The "Controller" that accepts the raw stream, parses messages, and mutates models.
	### Lifecycle Rules
	* **Surface Lifecycle**: It is an error to receive a createSurface message for a surfaceId that is already active. The processor MUST throw an error or report a validation failure if this occurs.
	* **Component Lifecycle**: If an updateComponents message provides an existing id but a different type, the processor MUST remove the old component and create a fresh one to ensure framework renderers correctly reset their internal state.

[gemini-code-assist]

The original renderer_guide.md included detailed pseudo-code examples for React and Angular adapters (Strategies 2 and 3). These examples provided essential context for how to implement the binder layer and manage framework-specific lifecycles. Removing them reduces the practical utility of this guide for developers in those ecosystems.