fix(sdk): Get trace context from provider

[namrataghadi-galileo]

Summary

• Use a provider provided trace_id and span_id if available for observability first.

Scope

Get provider specific trace context if available else get current trace_id and span_id.

Risk and Rollout

• Risk level: low
• Rollback plan:

Testing

• [ x] Added or updated automated tests
• [ x] Ran make check (or explained why not)
• [x ] Manually verified behavior

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...dks/python/src/agent_control/control_decorators.py	90.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[abhinav-galileo]

With a provider registered, this returns the provider's span_id verbatim, so every @control() call inside one provider-owned span now reports under the same (trace_id, span_id) pair — both the pre and post _evaluate POSTs, and any stacked decorators in the same trace. The docstring above frames this as intentional. Flagging as FYI: this is a semantic change from the old path, where get_current_trace_id() already returned the provider's trace_id and _generate_span_id() was minted fresh per decorated call (see tracing.py:147-150). Consumers that group control events by (trace_id, span_id) will now see them collapse onto one span; if the bridge keys events by control_execution_id this is fine. Worth a brief inline code comment so future readers don't expect a fresh span per decorator like the fallback branches still produce.