docs(spec): fix two v1.0 evolution guide inaccuracies (functionResponse, Icon.name)

[dongai-z]

Description

Two documentation-only corrections to specification/v1_0/docs/evolution_guide.md.
Both align the guide with the existing v1.0 schema; no schema or code behavior changes, so no tracking issue was filed first.

1. functionResponse description (§ Client-to-server events)

The functionResponse entry is inaccurate in two ways:

• It references a type name FunctionResponseMessage that does not exist. client_to_server.json has no $defs; its messages are inlined as top-level properties (action / functionResponse / error), so there is no FunctionResponseMessage identifier.
  grep -c "FunctionResponseMessage" specification/v1_0/json/client_to_server.json → 0
• It says functionResponse returns "(value or error)", but the schema is required: [functionCallId, call, value] with unevaluatedProperties: false — it carries only a value, never an error. Function execution failures are reported via the separate error message (which carries a functionCallId), as already documented in the very next bullet of the same section.

Fixed: drop the non-existent name, state that functionResponse returns the successful value, and point to the separate error message for failures.

2. Icon.name DataBinding removal (§ Standard catalogs + Migration guide)

v1.0 renamed the custom-SVG field svgPath to path. As a side effect, the custom-SVG object {path} became structurally identical to a DataBinding {path}, making the Icon.name oneOf ambiguous. v1.0 therefore removed the DataBinding branch from Icon.name:

• v0.9.1 Icon.name = oneOf[ enum, {svgPath}, DataBinding ] (3 branches)
• v1.0 Icon.name = oneOf[ enum, {path} ] (2 branches; DataBinding removed)
• grep -c "DataBinding" specification/v1_0/catalogs/basic/catalog.json → 0

This is a breaking capability change: in v0.9.1 Icon.name could be data-bound; in v1.0 it cannot. The guide previously recorded only the svgPath → path rename and never mentioned the DataBinding removal or the resulting loss of data-binding — an undocumented breaking change.

Fixed: add one entry under the basic-catalog changes and one note in the migration guide. The schema already reflects the removal; this only documents it.

Pre-launch Checklist

One time:

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have built and run at least one sample.

For this PR:

• I have added updates to the CHANGELOG.
• I updated/added relevant documentation.
• My code changes (if any) have tests.
• If my branch is on fork, I have verified that scripts/e2e_test.sh passes.

If you need help, consider asking for advice on the discussion board.

[gemini-code-assist]

Code Review

This pull request updates the evolution_guide.md documentation to reflect the removal of the DataBinding option from the Icon component's name property, clarify that functionResponse only returns successful results, and add corresponding migration steps. The review feedback suggests improving the clarity of the JSON structures by replacing {path} with {"path": "..."} and correcting the terminology regarding component updates via updateComponents to refer to updating the component tree.

[gemini-code-assist]

Using {path} without quotes can be slightly confusing since it looks like a placeholder rather than a JSON object structure. Wrapping it in backticks and showing it as a JSON-like object (e.g., {"path": "..."}) makes it much clearer that it refers to a specific JSON structure.

Suggested change

	- Removed the `DataBinding` option from the `Icon` component's `name` property. Because `svgPath` was renamed to `path`, the custom-SVG object `{path}` became structurally identical to a `DataBinding` `{path}`, making the `name` `oneOf` ambiguous. As a result, `Icon.name` can no longer be data-bound; it must be a literal enum icon name or an inline custom SVG `{path}`.
	- Removed the `DataBinding` option from the `Icon` component's `name` property. Because `svgPath` was renamed to `path`, the custom-SVG object `{"path": "..."}` became structurally identical to a `DataBinding` `{"path": "..."}`, making the `name` `oneOf` ambiguous. As a result, `Icon.name` can no longer be data-bound; it must be a literal enum icon name or an inline custom SVG `{"path": "..."}`.

[gemini-code-assist]

Saying "resending the Icon component" might be slightly misleading because updateComponents requires the full component list (or at least a list containing the root component), so you cannot send just the Icon component by itself. Updating the phrasing to "updating the component tree" is more technically accurate. Additionally, using {"path": "..."} instead of {path} clarifies the JSON structure.

Suggested change

	- Stop data-binding the `Icon` component's `name` property; data binding on `name` is no longer supported. Use a literal enum icon name or an inline custom SVG `{path}`, and change an icon dynamically by resending the `Icon` component via `updateComponents`.
	- Stop data-binding the `Icon` component's `name` property; data binding on `name` is no longer supported. Use a literal enum icon name or an inline custom SVG `{"path": "..."}`, and change an icon dynamically by updating the component tree via `updateComponents` with the new icon definition.