Issue 209: a bundle's own SDK copy registers into a registry the runtime never reads; design 38 WP4 note

Found preparing WP4, before the first module's bundle was loaded beside the runtime's own:
proven with a two-copies probe, located in mesh-tools (node-tools), fixed by mesh-tools #32.
Design 38 WP4 records it and the two things the package left to the module — escalation
through sudo, and the filter file read from the manifest's path rather than a container env.

03-DESIGN/01-to-be/38-building-the-operators-machine.md

@@ -191,6 +191,18 @@ tool where they need root, which they have, since the runtime runs as the node's
 four machines; `docker ps` shows no `mesh-nftables`; `status` is well. Then the fail2ban holder
 proposed in an open change follows the same way when it lands.
 
+*Found 2026-10-03, before the step ran:* a bundle imported in-process brings its own copy of the SDK
+(WP3's *carry its dependencies*), and the SDK's tool registry is the copy's own — the first module
+loaded beside the runtime would have registered its tools where the runtime never looks, and served
+nothing, silently. Issue
+[209](../../04-ISSUES/209-a-bundles-own-sdk-copy-registers-into-a-registry-the-runtime-never-reads/00-report.md):
+the runtime now resolves every bundle's import of the SDK to its own copy, one registry and one
+broker per node. Two things the package did not say, settled in the module: the filter's commands
+run through `sudo` without a prompt where the runtime is not root, since the operator's account may
+escalate as the operator would; and a bundle has no environment of its own, so the tool reads the
+filter from the path the manifest's `filtering` names rather than from a variable the container used
+to carry.
+
 ## WP5 — The shell, on a server first
 
 *mesh-catalog #224, already written. Half a day to assign and prove.*