Lay the builds out before the start reads them, so the controller does not exit on its own start (issue 1121)

Delivery 2 (#381) gated every chain read on the layout marker and laid the
builds out beside the start; a read of the start then met the gate, the
controller exited, and systemd started it again every five seconds from
14:34 on 2026-10-18. The layout now runs once inside attachTheChain, before
anything reads; it skips keys laid out before, so it takes seconds, and a
failure is retried beside the serving as before.

cmd/mesh-controller/chain.go

@@ -43,8 +43,14 @@ func attachTheChain(ctx context.Context, inv *inventory.Inventory, server *link.
 	}
 	inv.UseChain(c)
 	inv.RequireLayout()
-	// And the builds laid out under their modules, once, before they are read (issue 1121).
-	go layBuildsOutSoon(ctx, inv)
+	// And the builds laid out under their modules, once, before they are read (issue 1121) — **before this returns**, so
+	// nothing the start goes on to read meets a chain not laid out yet: on 2026-10-18 the layout ran beside the start, a
+	// read of the start was refused, and the controller exited and was started again every five seconds. The layout of
+	// keys laid out before skips them, so this takes seconds; one that fails is tried again beside the serving, loudly.
+	if err := inv.LayBuildsOut(ctx, func(format string, args ...any) { fmt.Printf("chain: "+format+"\n", args...) }); err != nil {
+		fmt.Printf("chain: the builds are not laid out under their modules yet, and none is read until they are: %v\n", err)
+		go layBuildsOutSoon(ctx, inv)
+	}
 	// And the requests the move of delivery 1 found never handed over, asked again once (askAgain), once it is serving.
 	go askAgainSoon(ctx, inv)
 	// And what delivery 1 recorded of what each machine was sent, copied onto the keys of the assignments (CopySentBuilds).