add-blocking-tool

Create a Pending struct with a Notify and result Mutex, store it in a State map keyed by request_id, emit a request event, and await the notify in a tokio::select against cancellation. A command handler sets the result and calls notify_one to resume the awaiting future.

Regular tools are sync or async fire-and-forget and return their result immediately. Blocking tools need a round-trip: an event out to the frontend, a command back with the answer, and a Notify to wake the awaiting future before the model continues.

The tool is only wired in execute() without the sentinel and async dispatch in the tool loop, so its error string becomes the tool_result and the model thinks it ran. Wire both the sentinel and the request function in the run_turn dispatch chain.

The wire field names likely mismatch between core and frontend, such as the core emitting id while the web reads request_id. Ensure the event and reply command use identical field names on both sides.

Pending state lives only in memory, but the assistant tool_call is persisted, so a restart leaves an orphaned tool_call that wedges the session. On load, detect the trailing unanswered tool_call and re-present the prompt or synthesize a result.

Keep blocking tools orchestrator-only by not adding them to subagent::all_tool_names(). Subagents that need human input use contact_supervisor, which is a blocking tool scoped to subagents.