A file the mesh can deliver and cannot read

Everything else in a declaration is visible to whatever carried it. The
message is signed so it cannot be forged, and signing does not make it
unreadable — a password in `content` is a password the broker sees, which
is the transitive trust this design refuses everywhere else.

So a node generates a third key at enrolment and reports the public half,
exactly as it does for its identity and its overlay key. A file may
arrive `sealed` instead of `content`; the host opens it with that key and
writes the result. The control plane can then store a credential it
cannot use, and the broker relays a blob it cannot read.

A third key rather than reusing one of the two. The identity key signs
and is Ed25519; the overlay key is WireGuard's and is tied to being on
the private network, which a machine may not be. A key used for two
purposes is one rotation away from breaking the other.

Details that are not incidental:

- sealed and content together is refused, so "was this the secret or the
  placeholder" is answerable by looking
- a sealed file defaults to 0600 rather than 0644, because the
  consequence differs; an explicit mode still wins
- a node with no sealing key refuses the file rather than skipping it. A
  machine that quietly omits the one resource carrying a credential looks
  configured and cannot connect
- what is recorded is a digest of what was written, so drift on a
  credential is still detected without the node keeping the value, and
  the report that goes back over the broker carries neither

The key is made at enrolment rather than on first use. One made later is
one the mesh was never told about, so nothing could ever be sealed to it,
and the node would look fine and receive nothing.

This is why sealing was borrowed from another mesh's mistakes rather than
its design: there, credentials sit encrypted in the control plane's
database — which guards the database file and nothing else, since the
same value is also in each node's environment file in plain text and
inside every connection string composed from it. Its own tooling has to
search by value rather than by name to find the copies, and says the ones
inside composed URLs are usually the only copies in use.

internal/link/enrol.go

@@ -35,6 +35,11 @@ type EnrolRequest struct {
 	// and unreachable for a round trip, which is the state everything else here works to avoid.
 	OverlayKey string `json:"overlay_key,omitempty"`
 
+	// SealingKey is the public half of the key secrets are sealed to. A third key, and the
+	// reasoning is the same one twice over: the mesh must be able to send this node something
+	// nothing else can read, and it must never be able to read it either.
+	SealingKey string `json:"sealing_key,omitempty"`
+
 	Profile map[string]any `json:"profile,omitempty"`
 }
 
@@ -65,7 +70,7 @@ var ErrRefused = errors.New("the mesh refused this enrolment")
 // says once it is in, and the secret travels again because the control plane must not have to ask
 // the broker who connected.
 func Enrol(ctx context.Context, address, pin, node, secret string, public []byte,
-	overlayKey string, profile map[string]any, timeout time.Duration) (EnrolReply, error) {
+	overlayKey, sealingKey string, profile map[string]any, timeout time.Duration) (EnrolReply, error) {
 
 	config, err := PinnedConfig(pin)
 	if err != nil {
@@ -111,7 +116,7 @@ func Enrol(ctx context.Context, address, pin, node, secret string, public []byte
 	}
 
 	request := EnrolRequest{Node: node, Secret: secret, PublicKey: public,
-		OverlayKey: overlayKey, Profile: profile}
+		OverlayKey: overlayKey, SealingKey: sealingKey, Profile: profile}
 	body, err := json.Marshal(request)
 	if err != nil {
 		return EnrolReply{}, err