LangGraph RemoteTool coroutine blocks the event loop

Problem

LangGraph RemoteTool conversion exposes an async coroutine for the synchronous remote-tool callable, but the coroutine currently calls the sync callable directly.

For RemoteTool, that callable executes synchronous HTTP I/O through httpx.request(...). When the tool is invoked through async LangGraph execution, this can block the event loop until the remote request returns or times out.

This is not just an optimization gap: the current wrapper is worse than leaving StructuredTool.coroutine unset.

LangChain's StructuredTool._arun first checks whether self.coroutine exists. If it does, LangChain awaits it directly. If self.coroutine is None, LangChain falls back to the default async implementation, whose source comment says it is expected to delegate _run to a separate thread.

By supplying an async-shaped wrapper that directly calls a synchronous function, pyagentspec bypasses LangChain's safe default and runs blocking sync I/O on the event-loop thread.

Current behavior

_as_structured_tool_coroutine() wraps a synchronous callable like this:

async def _wrapped_async(*args, **kwargs):
    return func(*args, **kwargs)

That preserves the async API shape but still executes the blocking sync function on the event-loop thread.

For RemoteTool, the sync function eventually reaches httpx.request(...), so a slow or stuck remote service can block unrelated async work.

Expected behavior

The coroutine wrapper for sync callables should offload execution to a worker thread, while preserving native async callables unchanged.

This would restore the async-safety LangChain would otherwise provide when no coroutine is supplied.

Existing precedent in this codebase

ApiNodeExecutor already separates sync and async HTTP execution:

• _execute() uses sync httpx.request(...)
• _aexecute() uses httpx.AsyncClient

So the codebase already treats async HTTP execution as a first-class concern. RemoteTool is currently the outlier because its async entrypoint is async-shaped but not async-safe.

Impact

Any async host using LangGraph async execution can be affected. In services with event-loop based liveness/readiness handling, a slow or stuck remote tool request can freeze unrelated async work long enough to trip health checks and restart the service.

Suggested fix

Use asyncio.to_thread(...) for the synchronous wrapper path in pyagentspec.adapters.langgraph._langgraphconverter._as_structured_tool_coroutine().

This is a small general safety net for sync callables that pyagentspec intentionally exposes through a coroutine, including the current RemoteTool and ClientTool conversion paths. A future native async RemoteTool implementation using httpx.AsyncClient would still be compatible with this change and could further reduce thread usage for RemoteTool specifically.

Proposed PR

I opened #229 with a minimal fix and a regression test that simulates a blocking RemoteTool HTTP request and verifies the event loop remains responsive.

Start in pyagentspec.adapters.langgraph._langgraphconverter._as_structured_tool_coroutine() and review the existing regression test proposed in pull request #229. Verify that synchronous RemoteTool execution no longer blocks the event loop while native async callables remain unchanged.