Assistant node, and the Control tab as one conversation (openpanel V5)

run_turn takes its tools, system prompt and tool caller; the chat passes the
MCP tools as before. The assistant node offers one tool per wired target,
reads its other inputs as context, streams its reply a sentence at a time,
warms the provider on `listening` and says so when the provider is not there.
Completions share the per-server HTTP client. wren replies when nothing reads
`unhandled`, stt shows a note when nothing was heard. /ai/control lists one
conversation per entry node with the messages to watch.

docs/code/agents.md

@@ -67,11 +67,16 @@ works without it.
 
 ## Control
 
-A live [Wren node](../reference/node-types.md#wren) with both `prompt` and
-`actions` wired adds a **Control** tab to the chat. It uses the node's local
-model and needs no assistant provider.
+A live [Wren](../reference/node-types.md#wren) or
+[Assistant](../reference/node-types.md#assistant) node with its `prompt` and a
+`reply` or `actions` wired adds a **Control** tab to the chat. Wren uses its
+local model, the Assistant node the provider above.
 
-Choose a node, type a command, and inspect the reported actions: target
-message, value, confidence, and whether each action was applied.
-The node's `apply` and `min_confidence` settings decide whether it writes
-to devices. Control conversations stay in the browser and clear on reload.
+Choose a conversation and type a command. It goes out on the node's prompt,
+which is where a `stt` node writes what a device heard, so typed and spoken
+commands are one conversation: the words heard so far, the command, each
+reply, and the reported actions with their target message, value and whether
+each was applied. A node whose prompt is another's `unhandled` answers in that
+node's conversation. Wren's `apply` and `min_confidence` settings decide
+whether it writes to devices. Control conversations stay in the browser and
+clear on reload.