A build is taken in where its outcome is heard, and the build tool answers at once (issue 176)

The console's `build` tool answered "no build machine answered within 0s", handed a forge path to
git as written, and a build heard afterwards was recorded and never registered: recording and
registration lived only in the waiting caller, and the tool did not wait.

Now one function takes a build's outcome in — records it, parses the manifest, refuses a definition
naming an installation, registers the module with its source as the seat and path the request
carried — and both the waiting command and the daemon that follows the role's `built` event call
it. `build --wait 0` asks and returns with the id; `builds --log <id>` follows it. The seat verb
says `--self` for a repository given without a scheme.

internal/link/builds_nats.go

@@ -43,6 +43,20 @@ func (b *natsBuilds) Close() {
 	}
 }
 
+// Ask publishes the work and returns; see Builders.
+func (b *natsBuilds) Ask(ctx context.Context, request BuildRequest) error {
+	body, err := json.Marshal(request)
+	if err != nil {
+		return err
+	}
+	publish, cancel := context.WithTimeout(ctx, 30*time.Second)
+	defer cancel()
+	if _, err := b.js.Context().Publish(BuildWork(), body, nats.Context(publish)); err != nil {
+		return fmt.Errorf("cannot submit a build: %w", err)
+	}
+	return nil
+}
+
 func (b *natsBuilds) Submit(ctx context.Context, request BuildRequest,
 	wait time.Duration) (BuildResult, error) {