One runtime principal per node carries every assigned module's tools (hq ADR 0175, to-be 38 WP2.1)

Where the node-tools module is assigned, the machine's bus user list gains one principal of kind
node-tools in place of that module's own: it may subscribe every carried module's tool namespace
and every held seat's verbs on its node, read and follow every membership on its node, call any
tool anywhere, answer what it is asked — and consume nothing, because tools are what it runs.
Every other module keeps its own principal, so a module still serving tools from its container
holds its own credential until it moves.

Named exactly as the module it stands for, so `module issue` and `rollout mint` deliver its
credential through the path a module's already takes, into node-tools' own `broker` secret. The
runtime module's name is one constant in each of the broker and catalogue packages, held to one
string by the agreement test, because a rule turns on it.

internal/catalogue/runtime.go

@@ -0,0 +1,13 @@
+package catalogue
+
+// The node's tool runtime, as the catalogue knows it (novox/hq ADR 0175, to-be 38).
+//
+// **One module is the runtime.** Where it is assigned, one process per machine serves every assigned
+// module's tools and every held seat's verbs, on the host side, from the bundles each module's build
+// produced — and no module needs a container to reach the bus with its tools. The name is a constant
+// rather than a manifest field because a rule turns on it: the composer places the runtime's process
+// where this module is, and registration refuses the old pattern once this module exists.
+
+// RuntimeModule is the module that is the node's tool runtime. Mirrored in the broker package,
+// which composes a principal of its own for it; the agreement test there holds the two to one string.
+const RuntimeModule = "node-tools"