A module names the module its build stands on, not a copy of it

A fingerprint written into a recipe names one particular copy of the base — the
copy on whichever machine the person typing it was using. On any other mesh that
copy has never existed, so the build stops on its first line with a message
about an image nobody can look up. Three modules in the catalogue were in
exactly that state, and the line each of them replaced was equally dead.

A module now names the module and artifact instead, and the mesh answers with
what it holds. The builder is still a thing that clones, builds and answers: the
answer travels with the question, because only the mesh knows what it has.

A base the mesh has not built is refused before anything is built, naming which
module has to exist first.

internal/link/build.go

@@ -51,6 +51,18 @@ type BuildRequest struct {
 	// repository root, which is the ordinary case; a repository holding several modules names
 	// each by its own directory.
 	Path string `json:"path,omitempty"`
+	// Held is every artifact this mesh has built, keyed "<module>/<artifact>".
+	//
+	// **Sent with the asking rather than fetched by the builder** (novox/hq issue 044). A module
+	// says which module's artifact its build stands on; only the mesh knows which copy of that
+	// artifact *this* mesh holds, and the builder is deliberately a thing that clones, runs a
+	// build and answers — giving it a way to ask the mesh questions would make it something else.
+	// So the answer travels with the question.
+	//
+	// It is everything rather than only what this module needs, because what this module needs is
+	// written in a manifest the mesh has not read: it is inside the repository, and reading it is
+	// the build's first act.
+	Held map[string]string `json:"held,omitempty"`
 }
 
 // BuildResult is what a builder says back.