Build modules run at most as many steps as their node's build CPU gives, and say a check's phases

Each of mesh-build-go, -node and -image declares cores-per-step (6, 2, 2) and hands it to the
SDK puller, which bounds the configured capacity by floor(slice quota cores / cores-per-step),
read live; thread limits and the status tools follow the effective capacity (issue 1806's
follow-up: three Go checks on shanks' 12-core slice starved past the 30-minute step bound).
mesh-build-go says its lint and test phases with the ask id (issue 1890).

modules/mesh-build-node/cmd/mesh-build-node/cpu.go

@@ -15,6 +15,8 @@ import (
 func (m *Module) cpuLimits() buildcpu.Limits {
 	slots := 1
 	switch {
+	case m.Held != nil:
+		slots = m.Held.CapacityNow() // the capacity the puller judges by, bounded by the node's build slice
 	case m.Capacity != nil:
 		slots = m.Capacity()
 	case m.Settings != "":
@@ -32,5 +34,9 @@ func (m *Module) threadEnv() []string {
 // cpuStatus is what the status tool says of it: the limits a step is given, and what the kernel holds this runtime
 // to (its unit and its slice), read from its cgroup rather than assumed.
 func (m *Module) cpuStatus() map[string]any {
-	return map[string]any{"limits": m.cpuLimits(), "in-force": buildcpu.ReadInForce()}
+	out := map[string]any{"limits": m.cpuLimits(), "in-force": buildcpu.ReadInForce()}
+	if m.Held != nil {
+		out["capacity"] = m.Held.CapacityDetail() // the capacity judged by and why (issue 1806's follow-up)
+	}
+	return out
 }