A re-run does not replace the registered forge with whatever checkout it was given

Registering a module is an overwrite. Recording the forge's port ran `module add`
every time, so a genesis re-run pointed at an older catalogue would replace the
manifest of a forge that is built and assigned — with a push a few lines later.
Registering is only here so a settings row has a module row to hang on, and that
row is already there on a mesh that knows the forge. So: ask first, and skip.

Two comments narrowed to what is true. What follows the node's setting is what
the mesh derives from a module's ports — its container mapping, its filter rule,
its opening and what it serves. The forge's own address in its runtime's
environment (hq 088) and its route contribution's port do not, and are already
wrong for any port the mesh assigned. And a settings layer is the module's, not
one resource's: a second mergeable file on the builder would be given `serves`
too.

novox/hq 04-ISSUES/085

internal/bootstrap/ports.go

@@ -122,6 +122,12 @@ const PortsSetting = "ports"
 // builder — which a later registration from the catalogue undid silently. Set as a node's setting
 // instead, it is held by the controller rather than by the manifest, so re-registering the builder
 // leaves it where it was.
+//
+// **A settings layer is the module's, not one resource's.** The controller lays it over every file
+// of that module which merges as JSON, so `serves` lands in the package binding only because that
+// binding is the builder's one mergeable file. A second mergeable file added to the builder would
+// be given a `serves` key too, meaning nothing to whatever reads it. Worth knowing before adding
+// one.
 const ServesSetting = "serves"
 
 // setFoundationSettings tells the controller the ports this node gave a foundation module — and,