fix: honor checkpoint object in thread state updates - #7115

This PR silently reverts the Gateway-side client-context handling from #7051, which has nothing to do with the checkpoint fix and is not mentioned in the description.

At this head, services.py deletes _sanitize_request_client_context, the configurable["client"] strip, the config['context']['client'] sanitization, and the body.context["client"] forwarding (the sanitize_client_context import is gone too — its only remaining callers are inside deerflow.runtime.client_context itself). Consequences at head:

• body.config.configurable.client is no longer stripped, so arbitrary caller-supplied client data persists verbatim into configurable — which is written to the checkpoint store and echoed by the run API. This is exactly what the removed code guarded against.
• body.config.context.client reaches runtime.context unsanitized (unbounded/nested caller data; the prompt block is still safe because render_client_context_for_prompt re-sanitizes at render time, but the raw dict persists).
• Top-level body.context.client is now silently dropped instead of forwarded sanitized, so the feat(context): support client context capabilities #7051 feature stops working for SDK clients (dynamic_context_middleware reads runtime.context["client"] and now finds nothing).

Hard evidence this is a regression, not a refactor: 9 tests in backend/tests/test_gateway_services.py — a file this PR does not touch — pass at merge-base 92e9afe and fail at this head (..._propagates_sanitized_client_context_to_runtime_only, ..._sanitizes_config_context_client_without_body_context, ..._drops_configurable_client, ..._logs_dropped_client_fields_without_values, ..._does_not_log_a_clean_client, and test_start_run_forwards_sanitized_client_context_to_runtime_context_only x4 params). I ran both sides to confirm.

The description's validation note ("Related gateway services tests passed (422 cases)") does not hold at 155b439. Please drop every services.py hunk unrelated to checkpoint_ns — including the unrelated run_after_metadata comment reword further down — so the PR contains only the checkpoint fix, which as noted above is correct and complete.

[P2] Bind the mutation graph before using a nonempty checkpoint namespace

A valid checkpoint with a nonempty namespace passes the new existence check, but the subsequent accessor.aupdate() fails. LangGraph interprets checkpoint_ns as a subgraph path, while build_state_mutation_graph() contains only the mutation node and CheckpointStateAccessor.bind() does not provide the configurable checkpointer override needed to operate directly within that namespace.

I reproduced this with the locked LangGraph 1.2.9: persist a checkpoint by invoking a parent graph containing a child subgraph, then POST /api/threads/{thread_id}/state with that checkpoint's actual {thread_id, checkpoint_ns, checkpoint_id} selector and a title update. The lookup succeeds, but the request returns HTTP 500 (Failed to update thread state), with ValueError: Subgraph child not found from abulk_update_state. The same endpoint's root-namespace control succeeds.

Please make the mutation accessor support writes and readback in the selected namespace, and add a regression using a real persisted nonroot checkpoint that verifies the updated values and parent checkpoint ID. Both new tests currently use checkpoint_ns: "", so they miss this path.

[Suggestion] A checkpoint object with a nonempty checkpoint_ns but no checkpoint_id skips the if checkpoint_id is not None: existence check below, and with direct_namespace=True the write now succeeds into an arbitrary namespace. I probed this head: POST /api/threads/{id}/state with checkpoint: {"thread_id": ..., "checkpoint_ns": "child:ghost"} (no checkpoints exist in that namespace) returns 200 and materializes a brand-new checkpoint in child:ghost, confirmed via checkpointer.aget_tuple — root state stays intact, but the endpoint's 404 discipline for unknown selectors (the branch just below) does not apply to namespace-only selectors, and before this PR the state API could never create a nonroot namespace at all. Consider running the same ns-aware aget_tuple existence check whenever checkpoint_ns is nonempty, even without checkpoint_id, returning 404 when the namespace has no checkpoints.

[Nit] This reaches into LangGraph's private internals (langgraph._internal._constants); the repo so far imports private LangGraph modules only from tests. It works at the locked langgraph >=1.2.9,<1.3 — I verified CONFIG_KEY_CHECKPOINTER resolves at 1.2.9 — and the deferred import confines any breakage to the nonempty-namespace mutation path, but a minor upgrade that moves the constant would turn subgraph-namespace state updates into runtime 500s. Worth a brief comment naming that version coupling so the next langgraph bump knows to grep for it.

[P2] Keep child titles out of root conversation metadata

Now that a nonempty checkpoint_ns targets a child checkpoint, the later title synchronization at lines 1718–1725 also needs to respect that namespace. It currently calls thread_store.update_display_name(thread_id, new_title, ...) for every title update, so changing a child's title renames the root conversation in thread search results even though its root checkpoint was correctly left unchanged.

I reproduced this through the real thread/assistant/accessor builders with a persisted child subgraph in both full and delta modes: first name the root Root conversation, then POST a title update of forked with the child's {thread_id, checkpoint_ns, checkpoint_id} selector. The response is 200 and the child checkpoint has the correct selected parent; GET /api/threads/{id}/state still returns the root title Root conversation, but POST /api/threads/search now lists that conversation as forked. The root checkpoint itself is byte-for-byte unchanged.

Please restrict the update_display_name synchronization to the root namespace (not checkpoint_ns) and extend the namespace regression to assert that thread metadata/search titles remain unchanged after a child title update. A temporary in-memory version of that guard makes the failing full/delta probes pass without affecting the root controls.