Track RAG actions

Alright pushed some stuff straight into the main for now:

+ Add trace manager service - Core service and interface
+ Register trace manager service - Service definition
+ Use trace manager in AI subscriber - Refactored to use centralized trace logic
+ Register tool and search span subscribers - Service registrations
+ Track AI agent tool executions - Tool span subscriber
+ Track Search API queries - Search span subscriber for RAG

TLDR - now we can hierarchically track any tool-call and also we bolted in a specialized logic for ai_search_block (which doesn't use any tool) - basically if the ai_search query is performed, we create also a span for it.

More changes - as previous ones ignored some things:

I had to split the ai logging sub-module into 3 separate sub-modules: general ai, ai agents and search - because they actually depend on separate module:

• The trace manager now exposes high-level lifecycle methods (scheduleToolParent, claim/releaseToolParent, start/endDelegation, enter/leave/currentSpanContext). Also nuked some span-related tracking that we implemented earlier.
• LangFuseAiLoggingSubscriber registers active generations per thread ID, schedules tool parents when tool calls occur, and resolves parents via delegation/search contexts instead of scanning observations.
• LangFuseToolSpanSubscriber claims the queued generation parent, starts delegation when another agent is invoked, pushes/pops AI Search contexts, and releases claims using releaseToolParent() rather than a custom handle class.
• LangFuseSearchSpanSubscriber wraps Search API queries with span contexts so embeddings can attach to the retrieval span; contextual comments explain each step.
• LangFuseAgentLifecycleSubscriber documents that it registers parent runner relationships for delegation.

This structure keeps AI Agents and AI Search logging optional submodules (wiring only when those contrib modules are enabled) while preserving a single runner-context system the rest of the code can rely on.

After anlyzing this live with Frederik Wouters, we discovered that it misbehaves when used under Deepchat.

More fixes done:

Termination Flow Consolidation

Removed duplicate KernelEvents::TERMINATE handler from langfuse_ai_logging. The root LangfuseSyncSubscriber in web/modules/custom/langfuse/src/EventSubscriber/LangfuseSyncSubscriber.php now exclusively finalizes traces, updates metadata (final timestamp/output), clears the active trace, and runs syncTraces().

DeepChat-Friendly Trace Management

• Introduced LangFuseTraceSessionStorageInterface with a session-backed implementation (LangFuseTraceSessionStorage). It tracks thread→trace IDs so multi-request workflows (DeepChat’s “submit” + “tool follow-up”) can re-use the same trace.
• The AI logging subscriber now injects this storage instead of reaching directly into the request stack. Whenever a generation finishes without pending tool calls, it clears the thread mapping; otherwise, it leaves it in place.
• LangfuseSyncSubscriber::finalizeActiveTrace() checks whether the current trace still has mapped threads. If so, it skips finalization and syncTraces(), allowing the next request to resume the same trace. Only when all thread mappings are cleared does it finalize and sync.
• DeepChat’s two-step requests therefore stay within one trace: request #1 leaves the mapping (because tool calls were requested), the terminate event defers syncing, request #2 re-uses the trace and clears the mapping once complete, and only then does termination finalize and send the trace to LangFuse.

So last updates were as following:

- Kept unified terminate subscriber.
- But, removed the deepchat attempted integration - as it requires way more changes than I thought - especially SDK changes. I'll leave it for now as a separate ticket.

Done, made a new alpha1 release with this in it.
Thanks!