A Go tools bundle is served by its binary (hq ADR 0193)

A bundle compiled to a binary has no entrypoints, and loads had to name one, so a Go bundle could
not be served. Its binary is what the runtime starts: loads names the binary, derived when the
module lists tools, and the runtime is told the binary's path, delivered like any tools bundle.

internal/catalogue/build.go

@@ -87,6 +87,12 @@ func (m Manifest) Resolve(built []Built) (Manifest, error) {
 			loads := append([]string(nil), a.Loads...)
 			if a.Loads == nil && len(m.Tools) > 0 {
 				loads = append([]string(nil), a.Entrypoints...)
+				// A bundle compiled to a binary has no entrypoints: the binary is what it is, and what
+				// the runtime starts to serve it (novox/hq ADR 0193). So a Go tools bundle is served
+				// as Go — the runtime execs it — exactly as a TypeScript one is through its launcher.
+				if bin := BinaryOf(a); bin != "" {
+					loads = []string{bin}
+				}
 			}
 			// **Kept, never routed** (ADR 0155): the builder publishes to the store at the address
 			// it reached it by, and a manifest carrying that address names an installation —
@@ -242,6 +248,11 @@ func (b *Build) problems(module string) []string {
 				for _, e := range a.Entrypoints {
 					found = found || e == load
 				}
+				// A bundle compiled to a binary is one executable: the runtime loads that or nothing
+				// (novox/hq ADR 0193).
+				if bin := BinaryOf(a); bin != "" {
+					found = load == bin
+				}
 				if !found {
 					problems = append(problems, fmt.Sprintf(
 						"%s: %q says the runtime loads %q, which is not among its entrypoints — "+