One entry per mapping, under the name the module itself uses

Review found the first pass aliased its answer under both ends of a mapping, which is
wrong wherever two mappings share a number: the alias lands on a key belonging to another
mapping, the later write wins, and the filter and the container then disagree — the very
fault this change exists to close. Two reproduced cases: a module publishing 8080:80 beside
9090:8080 had an explicit setting silently overwritten; a module publishing 4001:80 beside
4002:80 composed both containers onto one machine port, where before it was safely refused.

Now a mapping's answer is filed once, under the end the module names in its listens — the
number the plan, the filter, the openings, the guard and the consumer all ask for — and a
key that names two mappings is refused in the same words as a setting that does.

Also: the guard assertion in the end-to-end test failed open when the resource was absent;
the plan-mirroring helper now says it stands in only where the plan does not allocate, and
the assertions it feeds are narrowed to the port under test.

cmd/mesh-controller/sendable_test.go

@@ -330,11 +330,15 @@ func TestTheMachineSideOfAMappingIsMovedEverywhereTheNumberIsUsed(t *testing.T)
 	if opening == nil || opening["to"] != 22 || opening["from"] != catalogue.OpeningFromMesh {
 		t.Fatalf("no opening for the port this node gave the forge: %v", opening)
 	}
+	var guard map[string]any
 	for _, r := range resources {
-		if r["id"] == catalogue.GuardID() && r["content"] != catalogue.AsGuard([]int{222}) {
-			t.Fatalf("the guard does not refuse the port the forge is on:\n%s", r["content"])
+		if r["id"] == catalogue.GuardID() {
+			guard = r
 		}
 	}
+	if guard == nil || guard["content"] != catalogue.AsGuard([]int{222}) {
+		t.Fatalf("the guard does not refuse the port the forge is on:\n%v", guard["content"])
+	}
 
 	// And the consumer on the other machine dials the same number.
 	plan, _, err := planFor(ctx, open, "laptop")