fix: avoid OTel "Failed to detach context" error on early run_async close

[GanziMan]

Fixes #6559.

Problem

record_invocation (schema v1, the default off Agent Engine) wraps
runners._run_node_async — an async generator — with
start_as_current_span("invocation"). When a caller stops iterating
Runner.run_async() early (a common break/return as soon as the final
response arrives), the generator is finalized (GeneratorExit /
CancelledError) in a different execution context than the one where the
span was attached. The automatic context detach() then raises
ValueError: <Token ...> was created in a different Context.

OpenTelemetry swallows that exception inside context.detach() but logs it at
ERROR (Failed to detach context) on every early-terminated run. The
invocation still completes correctly, so this is cosmetic — but it creates
significant log noise and false error-rate spikes (e.g. Datadog). Note that
OTEL_SDK_DISABLED=true does not suppress it, since attach()/detach() live
in the context API, not the SDK.

Fix

Manage the span/context explicitly and detach() only when the generator body
completed normally; skip detach() on early close. The span is always
end()ed, so trace data stays complete. Full consumption is unchanged.

Tests

Adds tests/unittests/telemetry/test_instrumentation.py:

• test_record_invocation_no_detach_error_on_early_close — reproduces the
  early-close path (via asyncio.run → loop.shutdown_asyncgens(), which
  finalizes the still-open generator in a different context) and asserts no
  Failed to detach context ERROR is logged, while the invocation span is
  still recorded and ended.
• test_record_invocation_full_consumption_still_records_span — full
  consumption keeps recording the span with no error.

Verified the new early-close test fails without this change (with the exact
ValueError: <Token ...> was created in a different Context) and passes
with it.

Scope

Intentionally minimal: only the default schema-v1 invocation span that users
hit today. The same start_as_current_span-around-async-generator pattern also
exists on the schema-v2 path (node_tracing._use_invoke_workflow_span) and can
get the same treatment in a follow-up.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.