perf(telemetry): skip non-recording LLM trace work

[dexhunter]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Related: Event streaming in run_async triggers repeated Pydantic serialization #4233

Problem:

trace_call_llm builds telemetry configuration and serializes request and response content before writing span attributes, even when the supplied or current span is not recording. A non-recording span cannot retain those values, so large LLM payloads incur avoidable CPU work.

Solution:

Resolve the span first and return when span.is_recording() is false. Recording spans keep the existing telemetry and attribute path unchanged. The regression test covers both explicitly supplied and current spans and proves that neither request nor response serialization runs on the non-recording path.

This addresses one narrow source of the repeated serialization reported in #4233; it does not claim to eliminate every serialization path in that issue.

Performance

The strict same-workload evaluator enables content capture and uses a large deterministic response. Each reported run is itself the median of nine benchmark batches.

Revision	Three repeated evaluator results (us/call)	Median (us/call)
Current main	153.056, 153.571, 154.278	153.571
This PR	0.122033, 0.122233, 0.125897	0.122233

That is a 99.92% reduction in this helper's non-recording-span overhead. This is a helper-level CPU benchmark, not an end-to-end agent or model latency claim. The evaluator also verifies that recording-span attributes and serialization behavior remain unchanged.

The early-guard direction was identified through autoresearch with Weco. The comparable baseline, patch, and hardened regression are recorded in this public autoresearch trajectory.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All focused unit tests pass locally.

Results on the final rebased patch:

• pytest tests/unittests/telemetry/test_spans.py -q: 80 passed, 1 skipped
• strict evaluator: three repeated upstream and candidate runs passed all recording/non-recording correctness gates
• uvx ruff check --fix src/google/adk/telemetry/tracing.py tests/unittests/telemetry/test_spans.py: passed
• repository hooks and git diff --check: passed

Manual End-to-End (E2E) Tests:

Not applicable for this tracing guard. The focused unit suite and strict evaluator exercise explicit and current spans, recording and non-recording behavior, request and response serialization, telemetry-disabled cases, tools/no-tools cases, and serialization fallback behavior without an external model request.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective.
• New and existing focused unit tests pass with my changes.
• I have manually tested my changes end-to-end. (Not applicable; see above.)

Additional context

The patch is intentionally limited to the non-recording trace path; recording-span behavior remains covered and unchanged.

[adk-bot]

Thank you @dexhunter for your contribution! 🎉

Your changes have been successfully imported and merged via Copybara in commit 0c63a89.

Closing this PR as the changes are now in the main branch.

[dexhunter]

Rebased onto current main at fa884e3d. The feature diff remains limited to tracing.py and test_spans.py.

Validation after the rebase:

• 81 passed in tests/unittests/telemetry/test_spans.py
• git diff --check upstream/main passed
• the PR branch is clean

The remaining repository-wide failures reproduce outside this patch on current main:

• tests/unittests/test_verify_snippets.py points to the missing open_source_workspace/.agents/skills/adk-verify-snippets/scripts/verify_md.py path, while the script is currently under .agents/...
• end-of-file-fixer modifies the current-main .agents/skills/adk-style/references/imports.md
• the mypy baseline comparison can report the same lite_llm.py enum union in a different literal order as a new error, despite identical source and equal error counts

I left those unrelated upstream issues out of this focused telemetry PR.