The console: mesh serve on loopback, and every runtime answers tools

The runtime serves a tools verb per module with names, descriptions and schemas (design 34 §3), and
refuses a module naming its own tool tools. Discovery asks catalog_modules then each module, naming
what did not answer. One MCP handler over two transports: stdio (mesh mcp) and loopback HTTP (mesh
serve, the mesh-console module, novox/hq ADR 0152); serve refuses any bind but loopback. tools/call
may go through a running console with --console and no credential.

README.md

@@ -25,6 +25,20 @@ MESH_TOOL_MODULES   /a/tools/index.js,…   the assigned modules' compiled tool
 `node dist/main.js`, or the container (`Dockerfile`). On a node the host resolves both variables
 and starts it like any other supervised workload.
 
+## `mesh` — the tools for whoever is on a machine
+
+The same package carries the client (novox/hq design 25 §7, design 34): `mesh tools`, `mesh call
+<module>.<tool> [json]`, `mesh mcp` (an MCP server over stdio for a program a person starts) and
+`mesh serve` (the **console**: MCP over HTTP on a machine's loopback, started by the mesh as the
+`mesh-console` module on the credential in `MESH_BROKER_FILE` — novox/hq ADR 0152). `mesh serve`
+refuses to bind anything but loopback. With `--console <url>`, `tools` and `call` go through a console
+already on the machine and need no credential.
+
+Discovery asks the modules: every runtime answers a `tools` verb for each module it serves, with names,
+descriptions and schemas from the code that answers them, and the console asks the catalogue which
+modules the mesh holds and each module what it serves. A module that does not answer is named, never
+dropped. A module may not name a tool of its own `tools`; the runtime refuses it at load.
+
 ## Verified
 
 `npm test` stands up LavinMQ (the mesh's broker) and proves the whole path over real AMQP: the