feat: confirmToolCall support — startToolCall with requireConfirmation + ToolRunnableCallable [JAR-9208]

[JoshParkSJ]

Changes

• Moves tool confirmation from the old interrupt-based flow to confirmToolCall on startToolCall:

1. Graph build — LangGraph's wrapping discards the original BaseTool reference; the typed subclass preserves .tool so the runtime can inspect it at init time (so we know which tools need confirmation before hitting the tool node and can pass require confirmation on startToolCall)
2. Runtime init — _get_tool_confirmation_info walks the compiled graph once, finds ConversationalToolRunnableCallable nodes, and builds a {tool_name: input_schema} lookup. This is needed because coded agents (create_agent) export a compiled graph as the only artifact — there's no side channel to pass confirmation metadata from the build step to the runtime.
3. Streaming — mapper checks the lookup on every AIMessage tool call, emits startToolCall with requireConfirmation: true and inputSchema.

• fixes AIMessageChunk self-accumulation bug that doubled tool names on the first streamed chunk (only triggered with OpenAI, not Claude); startToolCall now always emitted for confirmation tools
• rip-and-replace as we see zero production usage confirmed via App Insights telemetry (90 days)

Companion PRs

• AgentInterfaces#899 — CAS frontend
• uipath-python#1558 — confirmToolCall model + bridge
• uipath-runtime-python#104 — remove emit_interrupt_event
• uipath-agents-python#420 — skip HITL during eval

https://uipath.atlassian.net/browse/JAR-9208

[JoshParkSJ]

not a problem for low code agents, but might as well unify how we get tools requiring confirmation

[maxduu]

Is this what causes the duplicate tool name issue? I remember @shannonsuhendra wrote that this issue wasn't happening anymore.
If this change is risky maybe we can move to a different PR?

[JoshParkSJ]

It happens only for GPT models. You can see it happen consistently in staging rn

[JoshParkSJ]

updated the comment so it's clear this is for gpt only bug

[maxduu]

This part seems a little sketchy to me in terms of typing. It would be nice if the runtime.py code has the tool field typed, or at least can do an if isinstance ... to get the right class typing.
Some questions:

• Any way we can add the fields needed by the tool to some metadata within RunnableCallable?
• At the very least we don't need to do any for func, afunc in ConversationalToolRunnableCallable? But if we could do the first bullet it might be even better

Would be nice to get a look from @cristipufu when approach is finalized as well.

[JoshParkSJ]

Unfortunately RunnableCallable is a langgraph class, not ours to touch. Fixed func/afunc and if isintance ...

If you think ConversationalToolRunnableCallable is just ugly/excessive then we can force assign node.tool like this. Not sure if that's better though

    node = RunnableCallable(func=_func, afunc=_afunc, name=tool_name)

    tool = getattr(tool_node, "tool", None)
    if isinstance(tool, BaseTool):
        node.tool = tool  # type: ignore[attr-defined]

    return node