Issue 094 resolved: a given port names either end and is answered once

The first pass answered under both ends, which review showed is the same fault seen
from the other side where two mappings share a number. Verified on the machine: the
forge is back on the port its own configuration has always advertised.

04-ISSUES/094-a-port-published-as-the-machine-side-cannot-be-moved/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-23
 located-in: [mesh-controller internal/catalogue/filtering.go, mesh-controller cmd/mesh-controller/plan.go]
-fixed-by:
+fixed-by: mesh-controller — a node may move a port a module publishes as a mapping's machine side
 amended-design:
 ---
 

04-ISSUES/094-a-port-published-as-the-machine-side-cannot-be-moved/01-diagnosis.md

@@ -53,3 +53,28 @@ still **stored** without a manifest in view, so a key that names nothing a modul
 accepted where it is set and refused at composition — where it stops the node being told anything
 at all, rather than stopping that module. The fix removes one reason a key could be wrong; it does
 not remove the shape of the failure. Carried to [issue 096](../096-a-setting-that-cannot-work-is-stored-and-stops-the-node/00-report.md).
+
+## Resolved — 2026-09-23
+
+A given port names either end of a mapping and is answered **once**, under the end the module
+names in its own `listens` — the number the plan, the filter, the openings, the guard and the
+consumer all ask for. A number that names two of a module's mappings is refused, whether the
+setting used it or the answer would be filed under it.
+
+The first pass filed the answer under both ends. Review found that this is wrong wherever two
+mappings share a number: the second key lands where another mapping's reader looks, the later
+write wins, and a module publishing `8080:80` beside `9090:8080` had an explicit setting silently
+replaced — the container moving to one number while the filter, the opening and the consumer kept
+another. Reintroducing the fault, inside the fix for it. Two mappings onto one machine port came
+with it, where before the setting had been safely refused. Neither was reachable against the
+catalogue as it stands; both were silent, which is worse than reachable.
+
+**Verified on the machine**, not only in tests: the forge was given `{"2222": 222}`, its container
+now publishes `222:22`, the opening derived for it is `tcp-222-forwarded` to 22 from anywhere —
+the node's `expose` for that port carried across the move — and nothing is opened at the number it
+left. Git over ssh answers from outside again, on the port the forge's own configuration has
+advertised in every clone URL all along.
+
+Checked from the other side as well, and it matters: `SSH_PORT` in the forge's configuration says
+222. While the port could not be moved, the mesh published 2222 and the forge told everyone 222.
+A service can be wrong about itself without anything failing.