Spans that end in ERROR don't set error.type (only tool spans do)

Finding: When google-adk at main commit 3c31fa510 (Linux, Python 3.11.16, mocked gemini-2.5-flash) handles a failed model call, the reporter says the invocation/invoke_workflow, invoke_agent, call_llm and generate_content spans end with ERROR status but carry no error.type attribute. Only execute_tool sets it, via trace_tool_call (source: https://github.com/google/adk-python/issues/7494). Reported evidence: the metrics for the same operations do record error.type. In the inference-error-resource-exhausted case the reporter says the generate_content and invoke_workflow metric points carry "429", and in inference-error-valueerror they carry "ValueError", while the matching spans have none. The GenAI semantic conventions are said to expect error.type on spans that ended in error, so trace filters or alerts keyed on it would miss these failures (same issue). The reporter says the repository already tracks the gap. In tests/unittests/telemetry/test_semconv_conformance.py, test_error_status_implies_error_type is a strict xfail for four cases. The reporter's reproduction is to run pytest on that file with --runxfail and -k error_status_implies_error_type. The reported result is 4 failed, 60 passed, with the message excerpt "ERROR spans without error.type" (not the full assertion output). The failing cases are the resource-exhausted v1 and v2 schemas, valueerror v2, and tool-error-valueerror v2 (same issue). Hypothesis, not maintainer-confirmed: the reporter suggests most of these spans get ERROR from OpenTelemetry's start_as_current_span when an exception escapes, which records the exception but does not set error.type. The workflow span goes through a separate path in node_tracing.py, where a node returns its failure as data and the span is marked ERROR explicitly without the attribute (same issue). Expected behavior per the report: every ERROR span has error.type, with the same value as tracing.resolve_error_type() gives for the metric. Status and limitations: this is a single external report that KFA did not reproduce. No maintainer comment appears in the captured timeline, which is an initial head/tail capture and may omit middle comments. The reporter says a fix is ready and a PR will follow, but no PR, commit or release is in the supplied sources, so fix and release status are unknown. No workaround is stated.