Trace is stored in global state, possibly leaking traces across requests/users

Picking this up - btw this one might be tricky, I had buried a task related to this, I'll explain:

Deepchat interface - when used with Assistants / Agents, and those using delegation and/or toolcalls - sometimes interrupts each "next step" as a separate AJAX request - and normally this resulted in fragmented traces (i.e. each ajax request = 1 trace) - which made things unusable from tracing perspective -> you couldn't get the full "hierarchical chain" of step 1 -> tool-call 1 -> step 2 -> etc.. but you'd get each step as a separate trace..

If I recall correctly - I think that state-based approach was me trying to fix that (but it wasn't 100% successful as in some cases traces would still end-up broken-up).

I'll test before/after with both ai_search_block and deepchat to see how differently it behaves (and maybe now with latest Opus might figure out an elegant solution).

Flagging a coupling rather than reviewing the code. I have read the branch as a diff, not checked it out or tested it, so treat none of this as a verdict on the implementation.

The State key being removed is doing two jobs. It is the current-trace pointer, which is the bug reported here, and it is also what keeps a single Deep Chat turn inside a single trace, since one turn is split across several AJAX requests. Scoping it to the request fixes the leak and drops the stitching at the same time, which is #3561460. Worth weighing that the trace splitting is something we hit regularly, while the leak is derived from reading the code and has not actually been observed on a running site.

Moving to Needs work for that reason, not for anything in the diff. The suggestion is to keep this branch as the base, add the thread-keyed pointer from #3561460 on top, and verify the combined change across plain chat, AI Search Block and Deep Chat, with and without an assistant, checking that one turn still yields one trace. Happy to do that second half here rather than opening a competing MR.

Pushed seven commits on top of mr.baileys' two, which are rebased onto current 1.x with authorship unchanged. The branch now also closes #3561460, since the two cannot be separated: removing the global pointer takes conversation stitching with it, so the replacement had to land in the same merge.

One commit deserves a closer look than the rest. 8a65cfc scopes conversation to trace mappings to their owner. Thread IDs are assistant_thread_{uid}_{i}, so they are predictable rather than secret, and DeepChatApi accepts whatever thread_id a client posts without checking who it belongs to. Before this commit, posting another user's thread ID recorded your observations against their trace. The AI module is unaffected because its own history lives in a PrivateTempStoreFactory; our store did not have that protection.

The stitching works by reusing the trace ID across the requests that make up one turn, since LangFuse upserts on trace ID. That needs dropsolid/langfuse-php-sdk 1.2.1, which adds an optional $id to the Trace constructor and is a backport of behaviour 1.3 already has. The module's ~1.2.0 constraint covers it, so no dependency change is required. A turn is bounded by the request carrying a real user message, so separate turns still get separate traces rather than a whole conversation collapsing into one.

Verified against a local/live LangFuse instance: two turns produce two traces, continuation polls join the turn already in progress, one user cannot continue another's, an expired mapping starts a new trace rather than failing, and two staggered concurrent users are both recorded. That last one used to lose the second user's data entirely, which is worth stating because the symptom was silent: the request succeeded, the answer was correct, and only the observability vanished. 21 tests, 152 assertions, phpcs clean, phpstan unchanged.

Still open and not covered here: a turn that fans out to an agent across several polls. The single-request agent cascade is confirmed working, with tool and retrieval spans nested correctly, but the multi-request version has not been exercised.

Fixed the cspell failure

Also verified the trace-continuation logic end to end. It needs dropsolid/langfuse-php-sdk 1.2.1: 1.2.0 silently drops the trace ID passed to createTrace(), so ThreadTraceStore's stored ID never actually reaches the SDK. Bumped to 1.2.1 locally and reran the suite: all Unit/Kernel/Functional tests pass, including the two that fail against 1.2.0 (testContinuationRequestsShareOneTrace, testNewTurnStartsNewTrace).

Pipeline is still red on phpstan, but all 4 errors are pre-existing "should return static(...)" false positives in files this MR doesn't touch (langfuse_example's two forms, langfuse_feedback's controller, LangFuseSettingsForm).

other then that Its RTBC.