[v0.10 Proposal] Universal Dynamism: Making all component properties dynamic by default

This proposal introduces a foundational shift in the A2UI protocol for version 0.10: **Universal Dynamism**.

#### Overview
In previous versions (v0.8, v0.9), component properties were explicitly categorized as either static (e.g., `string`, `number`) or dynamic (e.g., `DynamicString`). This forced developers and AI agents to constantly consult the specification to determine if a specific property supported data binding or function calls.

**Universal Dynamism** removes this distinction. In v0.10, every visual or behavioral property of an A2UI component (excluding structural identifiers like `id` and `component`) will support the full range of dynamic capabilities: literal values, data model bindings (`path`), and client-side function calls (`call`).

#### Rationale
1. **Developer Ergonomics**: Simplifies the mental model. If a property exists, it can be bound to data.
2. **LLM Efficiency**: Reduces token usage in prompts by eliminating the need to explain which fields are dynamic.
3. **Reactive Layouts**: Enables data-driven layout changes (e.g., binding a `Column`'s `justify` property or a component's `weight` to the data model).
4. **Implementation Uniformity**: Streamlines renderer logic by allowing a single "Dynamic Resolver" path for all properties via the Generic Binder.

#### Proposed Specification Changes

**1. JSON Schema Refactoring (`common_types.json` & `basic_catalog.json`)**
- **Promotion of Dynamic Primitives**: All component property definitions in catalogs should migrate from raw types (e.g., `type: "string"`) to dynamic references (e.g., `$ref: "common_types.json#/$defs/DynamicString"`).
- **Dynamic Enums**: For properties with a fixed set of allowed literal values (like `variant`, `align`, `fit`), we will introduce a schema pattern that validates the literal enum values while still permitting objects containing `path` or `call`.
- **Nested Structures**: Component schemas will explicitly support arbitrary nested objects and arrays, provided that the leaf values of these structures are defined as dynamic primitives. This allows components to have structured "config" objects while maintaining full reactivity.

**2. Protocol Documentation Updates (`a2ui_protocol.md`)**
- **Changes from v0.9**: Add a dedicated section describing the "Everything is Dynamic" philosophy.
- **Data Binding Section**: Reframe the explanation to show that dynamism is the baseline for the entire component property tree, not just specific "content" fields.
- **Type Conversion**: Clarify how renderers should handle coercion when a dynamic property (like an enum `variant`) receives an unexpected value from a data binding.

#### Impact on Renderers
The reference `web_core` renderer's `GenericBinder` must be updated to recursively traverse any nested property structure defined in a Zod schema and apply reactive subscriptions to every leaf node. Performance optimizations should ensure that literal values are treated as "Constant Signals" to avoid unnecessary reactive overhead.

The changes are in the JSON schema files (common_types.json, basic_catalog.json) and the protocol documentation (a2ui_protocol.md). The web_core renderer's GenericBinder must be updated to handle recursive property traversal. Start by examining the current schema definitions and the GenericBinder implementation to understand the existing static/dynamic separation. 'Done' means all component property definitions reference dynamic types and the binder supports nested structures.

由索引模型根据 Issue 内容生成。