Write out what this node says when it joins, for the mesh to read

The enrolment request is a struct in each repository, and this node now
reports a third key — the one its secrets are sealed to. That wiring had
tests on each side and had never been run across the join, where a
renamed field fails silently: enrolment succeeds, the key is absent, and
the node looks joined until the first thing sealed to it cannot be
opened.

So this writes a real one — keys generated the way enrolment generates
them, not typed as literals — and the private half of the sealing key
beside it, so the other side can prove what it sealed is openable rather
than merely present.

The mirror of the declaration check that already runs the other way.

README.md

@@ -195,3 +195,29 @@ repository carries implementation and does not carry decisions.
 - `02-DECISIONS/0039-the-link-is-the-security-boundary.md` — a node owns no password
 - `02-DECISIONS/0041-the-host-depends-on-nothing.md` — why this is a static binary, and Go
 - `04-ISSUES/007-an-installed-package-is-not-a-capability` — why detection works this way
+
+## Checks that cross into the control plane's repository
+
+Two things are agreed between this repository and `novox/mesh-control`, and each is a separate
+struct on each side. A field renamed on one of them fails **silently** — the crossing succeeds and
+something is simply absent — so both are checked by handing one side's real output to the other's
+real parser. Neither runs by default; each skips with a reason, because a repository that fails
+without its neighbour checked out is a repository nobody can build.
+
+**What the mesh sends, read by this host:**
+
+```
+mesh-control:  ./build/mesh-control plan <node> --json > /tmp/d.json
+mesh-host:     MESH_EMITTED=/tmp/d.json go test ./internal/declaration/ -v
+```
+
+**What this node says when it joins, read by the mesh:**
+
+```
+mesh-host:     MESH_ENROL_OUT=/tmp/enrol.json go test ./internal/link/
+mesh-control:  MESH_ENROL=/tmp/enrol.json make check
+```
+
+The second writes the private half of the sealing key beside the request, so the mesh's suite can
+prove that what it sealed is openable rather than merely present. A key that is correctly named
+and simply *wrong* passes every check that only looks at the message.