fix(integrations): ensure that GEN_AI_AGENT_NAME is properly set for GEN_AI spans under an invoke_agent span

[constantinius]

Description

chat and execute tool spans under an invoke agent span should have the agent name property set

Issues

Closes https://linear.app/getsentry/issue/TET-1293/make-sure-that-agent-name-is-set-on-all-of-its-gen-ai-children

[linear]

TET-1293 Make sure that agent name is set on all of its gen_ai.* children

[codecov]

Codecov Report

❌ Patch coverage is 36.36364% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.90%. Comparing base (76cc416) to head (5043e91).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
sentry_sdk/integrations/langchain.py	36.36%	5 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5030      +/-   ##
==========================================
- Coverage   83.93%   83.90%   -0.03%     
==========================================
  Files         179      179              
  Lines       17890    17901      +11     
  Branches     3181     3183       +2     
==========================================
+ Hits        15016    15020       +4     
- Misses       1909     1914       +5     
- Partials      965      967       +2     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/langchain.py	67.93% <36.36%> (-0.80%)	⬇️

[sentrivana]

I took the google-genai part out of this PR and merged it separately since it was straightforward: #5038

Regarding the Langchain part, we talked about this and I also thought about it a bit more. Documenting my reasoning and the proposed path forward for this sort of pattern here.

The problem: We need access to some package-internal object (in this case the agent) to be able to extract something from it in different places in the integration.

In this PR, we're opting for storing it on the current scope in the _contexts. I'm unhappy about this since we're misusing a field whose purpose is something entirely different (populating contexts on events) to store something integration specific.

Other solutions that have been proposed:

• Store it on something coming from Langchain directly that gets passed around and is accessible everywhere we need it. This is the usual way of doing things, but we couldn't find a good candidate here.
• Store it on the parent transaction and access it from there. The problem here is there might be different agents in a transaction.
• Store it on a parent span and access it from here. But there is no good way of traversing the span tree.

TL;DR: recommended way forward:

My recommended solution would be to store this in a ContextVar on the top level of the integration. That way, we have the same execution context isolation that we have with scopes (they're also context vars), but we're not misusing _contexts, and we're keeping the change contained to the integration.

Alternatively, can this be filled in in relay? I.e., we set the agent name on the topmost span that makes sense, and relay copies it to all child spans where it makes sense.