Issue 171: a module that names its own resolver knows no mesh name

Found and fixed the afternoon ADR 0148 landed: mailu-admin lost its
database behind Mailu's own resolver. Two catalogue PRs; an insight on
0148 that a container's dns is a decision, not a preference.

02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md

@@ -150,6 +150,16 @@ closed by this record, only answered by it.
   resolvable inside the mesh — holds unchanged and by the same means the machine already uses.
 - **Issue 110 stops being a container-DNS inconvenience and becomes a prerequisite** for the mesh not
   restarting itself whenever it learns a name.
+- **A container that names a resolver of its own has opted out of the machine's**, and the copy this
+  record removes was the only reason such a container could reach anything by a mesh name.
+
+  > **Progressive insight — 2026-09-30, the afternoon this landed. Found the hard way.** The mail
+  > system's admin, behind Mailu's own resolver, lost its database the moment the copy went
+  > ([issue 171](../04-ISSUES/171-a-modules-own-resolver-knows-no-mesh-name/00-report.md)). A `dns` on
+  > a container is a decision about whether mesh names exist inside it, not a preference; the module
+  > was corrected, and whether the controller should refuse the contradiction is that issue's open
+  > question.
+
 - **A container started by hand gets the mesh's names too**, where before only declared containers did.
   Design 08 drew that boundary deliberately, on the grounds that reaching into every container is what
   a nameserver would be for. This record accepts that consequence rather than working around it: a