feat(tracing): expose provider tool call IDs on function spans

[HyeonsangKim]

Summary

• Add an optional tool_call_id to FunctionSpanData and function_span() so tracing processors can correlate tool spans with provider calls.
• Forward canonical call IDs for function, computer, shell, custom, and apply-patch tools, including concurrent calls that complete out of order.
• Preserve the released v0.22.0 positional API and keep the current default OpenAI traces ingest wire shape by removing the SDK-only field only in the endpoint-specific sanitizer. Custom processors and custom endpoints retain the field.

This addresses the gen_ai.tool.call.id gap documented in open-telemetry/opentelemetry-python-genai#90 without adding OpenTelemetry dependencies or correlation state.

Test plan

• UV_CACHE_DIR=/tmp/openai-agents-uv-cache uv run --frozen pytest -q tests/test_trace_processor.py tests/test_tracing.py tests/test_source_compat_constructors.py tests/test_run_step_execution.py tests/test_computer_action.py tests/test_shell_tool.py tests/test_custom_tool.py tests/test_apply_patch_tool.py (274 passed)
• UV_CACHE_DIR=/tmp/openai-agents-uv-cache /usr/bin/env -u OPENAI_API_KEY OPENAI_AGENTS_TEST_IN_CODEX_SANDBOX=1 UV_DEFAULT_INDEX=https://pypi.org/simple bash .agents/skills/code-change-verification/scripts/run.sh (format, lint, typecheck, and tests passed)
• Two independent final reviews of the same fingerprint returned clean with no findings.
• codex review --base origin/main completed clean and reran the affected tests (98 + 176 passed).

Issue number

Related: open-telemetry/opentelemetry-python-genai#90

Checks

• I've added new tests, if relevant
• I've run .agents/skills/code-change-verification/scripts/run.sh
• I've confirmed all verification steps pass
• If using Codex, I've run /review before submitting this PR

[seratch]

The integration need and the overall API direction look valid, but the current head is not mergeable: 7 of 18 CI jobs fail, covering Linux Python 3.10-3.14 and Windows Python 3.10/3.13.

One concrete uncovered surface is MCP tracing. MCP tools are converted to FunctionTool, so the _FunctionToolBatchExecutor change now adds tool_call_id to their function spans. The existing expectations in tests/mcp/test_mcp_tracing.py omit that field, and this PR does not update those tests.

Please inspect the full CI failures, update all affected MCP and normalized tracing expectations, and rerun the complete suite. Once the full matrix is green, I think this remains a good merge candidate.

[seratch]

Thanks for working on this. After re-evaluating the underlying need, I don't think we should expand the Agents SDK tracing contract yet.

The released OpenTelemetry processor already produces valid workflow and tool spans without this field, and gen_ai.tool.call.id is recommended rather than required. The current processor also does not consume the proposed attribute, so #4717 by itself does not change the OpenTelemetry output or resolve a demonstrated user-facing problem.

We can reconsider this if there is a corresponding OpenTelemetry implementation and a runtime reproducer showing that a supported scenario, such as concurrent same-name tool calls, is incorrectly or ambiguously correlated without the provider call ID and cannot reasonably be handled on the OpenTelemetry side. Until then, the new public field, cross-tool forwarding, and export-format expansion are not justified.