fix(core): Use reference counting for storing inherited run trees to support garbage collection

[Jacob Lee (jacoblee93)]

When a langsmith @traceable function invokes a LangChain Runnable or LangGraph subgraph, the callback manager's _configure function injects the @traceable RunTree into the LangChainTracer's run_map so that child runs can resolve their parent for trace nesting. However, since the RunTree was created outside the tracer's callback lifecycle, _end_trace never removes it. The entry persists in run_map indefinitely, retaining the full RunTree and its entire child tree.

In applications with nested subgraph invocations (e.g. an outer investigation graph delegating to skill agent subgraphs, each compiled as their own StateGraph), this causes RunTree objects to accumulate linearly with every call.

Fix: Track which run_map entries were injected externally via a shared _external_run_ids refcount dict on _TracerCore. When _start_trace adds a child under an external parent, it increments the count. When _end_trace finishes a child, it decrements — and evicts the external parent from run_map once the last child completes.

The refcount (rather than a simple set) is necessary because a single external parent may have multiple sibling children in the callback chain (e.g. a prompt | llm RunnableSequence). Only truly external runs are tracked — the _configure guard if run_id_str not in handler.run_map prevents tracer-managed runs from being misclassified.

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks
⏩ 29 skipped benchmarks¹

---

_{Comparing jacob/weakrefs (0c39cd4) with master (9ee4617)²}

Footnotes

1. 29 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (9f232ca) during the generation of this report, so 9ee4617 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Kevin K (torontodeveloper)]

hard to follow what's going on here with variable names are not self-explnatory

[Andrii Furmanets (afurm)]

The docstring mentions order_map and run_map can be shared between tracer instances, and _external_run_ids is also shared via the same constructor pattern — but unlike run_map/order_map, _external_run_ids isn't listed as an optional shared map in the docstring. Should its sharing semantics (or requirement for consistency with run_map) be documented to prevent silent misconfiguration?