Issues 102–106 and ADR 0105 from the core migration

Two birth-address outages and a registry that would have been the third; a
container that keeps a stale environment after its file changes; a host command
that applied a converged declaration to an adopted node; the hub and the vault
without seats. And the decision the operator made under it all: the hub adopts
the predecessor's tunnel in place, key and peers and range and port.

04-ISSUES/106-the-vault-claims-no-seat/00-report.md

@@ -0,0 +1,33 @@
+---
+status: open
+opened: 2026-09-23
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 106 — The vault claims no seat, so nothing refuses a second one
+
+## What was observed
+
+Reading the registry, 2026-09-23. The vault provides `secret` to the whole mesh and **claims no
+seat**. The store, the broker, the controller and the catalogue each claim one, named after
+themselves, so that a second claimant is refused at resolution
+([ADR 0079](../../02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md)). The vault
+was added after that record and did not inherit the rule.
+
+## Why it matters beyond this instance
+
+The vault holds every credential the mesh mints. A second vault, assigned by mistake or by a module
+that provides `secret` itself, would answer requirements the first was answering, and nothing in
+resolution would object. Of all the components to allow two of silently, this is the one to allow
+least.
+
+The rule is already written; this is an instance it was not applied to. Worth asking whether
+others were missed the same way — every provider added after 0079.
+
+## Open questions
+
+- A mesh-scoped seat `mesh-vault`, by the 0079 convention — is there any reason not to?
+- Should a provider of a mesh-scoped provision be required to claim a seat, or say explicitly that
+  more than one is allowed, so the omission cannot recur?