node-tools is a module beside mesh-tools: the runtime as a bundle, and serve is the console (hq ADR 0175, to-be 38 WP3)

One repository, two modules (ADR 0069). `node-tools/` holds the runtime — its code, tests, package
and the manifest of the module the controller composes a process for on every machine it is
assigned to: a bundle of `src/main.js`, the interpreter as a package, a place for the node's
credential, the loopback port the console declared, and leave to call every tool. Nothing about
how it runs: which bundles to load, where the credential is and whose machine it is are the
controller's to compose (WP2). The root module `mesh-tools` keeps the two images TypeScript
bundles are compiled in and a module's own service may run in; it is no longer how tools reach a
node.

As node-tools, `serve` is also the console (ADR 0175 §6): the same process answers MCP on
loopback for whoever is on the machine, through which the tools it serves can be called. A
module's own runtime in a container keeps serving without a listener.

The toolchain image now carries /app/runtime — a package.json saying the compiled files are ES
modules and the production node_modules — for the builder to copy into every TypeScript bundle,
so a bundle unpacked on a machine starts (ADR 0188 §5; the builder's side is the controller's).
Proven here by compiling node-tools with the toolchain's exact flags and starting the result.
The AMQP probe script is gone with the bus it probed.

Dockerfile

@@ -1,5 +1,8 @@
 ARG NODE_BASE=node:22-bookworm-slim
-# Three stages, two published images: the one modules are COMPILED in, and the one they RUN in.
+# The mesh-tools module: the two images every TypeScript module is COMPILED in and may RUN in. The
+# runtime itself ships as the node-tools module's bundle (node-tools/, novox/hq ADR 0175, to-be 38
+# WP3); these images are the toolchain for TypeScript bundles and the base a module's own service
+# may still be built on. They are no longer how tools reach a node.
 #
 # **They were the same image, and that was a mistake.** A module's recipe starts from this and
 # invokes the compiler out of it, so the compiler had to be here — and because the same image was
@@ -19,36 +22,42 @@ RUN apt-get update \
       && apt-get install -y --no-install-recommends git ca-certificates \
       && rm -rf /var/lib/apt/lists/*
 WORKDIR /app
-COPY package.json ./
+COPY node-tools/package.json ./
 # The builder writes .npmrc into the build context; it authenticates to the mesh's package registry
 # for the @novox scope, which is where @novox/mesh-sdk resolves. This stage is not published, so the
 # credential travels no further than here. Development dependencies included: the compiler is one.
 COPY .npmrc ./.npmrc
 RUN npm install --no-audit --no-fund
 
-# ---- toolchain: what a module is compiled in, WITHOUT the credential --------------------------
-FROM ${NODE_BASE} AS toolchain
+# ---- compiling: the runtime's own code built, WITHOUT the credential -------------------------
+FROM ${NODE_BASE} AS compiling
 WORKDIR /app
-COPY package.json ./
+COPY node-tools/package.json ./
 # The resolved libraries, but not the .npmrc that resolved them.
 COPY --from=deps /app/node_modules ./node_modules
-# The toolkit arrives compiled. It used to arrive as sources, and this compiled it by hand — the
-# hook that builds it on install was running all along, and the result was then packed out of the
-# package, because with no explicit file list npm falls back to .gitignore and that ignores the
-# build output. Fixed where it belonged, in the toolkit.
-COPY tsconfig.json ./
-COPY src ./src
+COPY node-tools/tsconfig.json ./
+COPY node-tools/src ./src
 RUN npm run build
 
-# ---- what the running image needs, and nothing else -------------------------------------------
+# ---- what a running bundle needs, and nothing else -------------------------------------------
 # Its own stage so the toolchain image keeps its build tools while the runtime image does not.
-FROM toolchain AS lean
+FROM compiling AS lean
 RUN npm prune --omit=dev
 
-# ---- runtime: what a module runs in -----------------------------------------------------------
+# ---- toolchain: what a TypeScript bundle is compiled in ---------------------------------------
+# Beside the compiler, at /app/runtime, what every TypeScript bundle runs with: the production
+# dependencies the SDK and the runtime need, and a package.json saying the compiled files are ES
+# modules. The builder copies this directory whole into a compiled bundle (novox/hq ADR 0188 §5),
+# so a bundle unpacked on a machine starts — a `.js` without that package.json is read as
+# CommonJS, and an import of `nats` without node_modules beside it resolves to nothing.
+FROM compiling AS toolchain
+COPY --from=lean /app/node_modules /app/runtime/node_modules
+RUN printf '{"type":"module","private":true}\n' > /app/runtime/package.json
+
+# ---- runtime: what a module's own service may run in ------------------------------------------
 FROM ${NODE_BASE} AS runtime
 WORKDIR /app
-COPY package.json ./
+COPY node-tools/package.json ./
 COPY --from=lean /app/node_modules ./node_modules
-COPY --from=toolchain /app/dist ./dist
+COPY --from=compiling /app/dist ./dist
 ENTRYPOINT ["node", "dist/main.js"]