A carried peer is nameable, and the mesh answers for it (hq 112)

The tunnel the hub took over routes to machines the predecessor knows
by name and the mesh knew only by address — taking the resolver in that
state silences three machines at once. Now the operator states which
machine a carried address is (overlay name <address> <name>), the
statement rides tunnel_peer.named, and namesInTheMesh answers for named
not-yet-enrolled peers — one reading, so the hosts fact, a container's
hosts and the resolver cannot disagree. Enrolment verifies the word:
a machine enrolling under a named peer's key with a different name is
refused where the operator can read it, the stated name keeps the
carried address, and an enrolled peer's name is the node's — naming it
again refuses. The issue's rule holds: a name the predecessor answers
for keeps resolving until the machine behind it is a node.

internal/inventory/migrations/0033-a-carried-peer-is-nameable.sql

@@ -0,0 +1,10 @@
+-- A carried peer may be named before it enrols (novox/hq issue 112).
+--
+-- The tunnel the hub took over routes to machines the predecessor knows by name and the mesh
+-- knows only by address. A name the predecessor answers for must keep resolving until the
+-- machine behind it is a node — so the operator may state which machine a carried address is,
+-- and everything derived from "the machines the mesh knows" (a container's hosts, the hosts
+-- fact, the resolver) answers for it in the meantime. The mesh records the statement as the
+-- operator's, unverified: enrolment is what verifies it, and enrolling under a different name
+-- than the one stated is refused rather than silently renamed.
+alter table tunnel_peer add column named text;