runtime: connect with a sealed credential, scoped, over pinned amqps (ADR 0048)

A module reads its broker credential from MESH_BROKER_FILE — the sealed
{url,fingerprint} the mesh delivered — and connects over amqps pinned to
exactly that certificate. The pin is two-phase (fetch cert, verify, then
trust only it), because Node's checkServerIdentity does not run under
rejectUnauthorized:false, so a naive connect-then-check would already have
sent the password to whoever answered.

A scoped module (assumeExchanges) never declares the exchanges (its account
may not) nor its own queue with a dead-letter (the broker refuses that to a
non-administrator) — the mesh pre-declared the queue, so it passively checks
it, binds and consumes. The RPC reply queue is lazy, and a module that
registered no tools serves none: a pure-events consumer touches only what its
account allows.

Verified end-to-end against a real broker as the scoped account: the audit
logger consumes # and records events, over an account that is not the
broker's own.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

src/runtime.ts

@@ -25,8 +25,11 @@ export async function runTools(opts: RuntimeOptions): Promise<() => void> {
     await import(pathToFileURL(resolve(entry)).href);
   }
 
-  const stop = await serveTools(opts.broker);
+  // Serve the RPC endpoint only if a module actually registered a tool. A pure-events module (the
+  // audit logger) registers none, and its scoped account may not declare the serve queue — so a
+  // runtime that always served would fail for exactly the modules that never needed it.
   const tools = listTools();
+  const stop = tools.length > 0 ? await serveTools(opts.broker) : () => {};
   console.log(`[mesh-tools] serving ${tools.length} tool(s): ${tools.map((t) => t.name).join(", ") || "(none)"}`);
   return stop;
 }