Ask mesh-delivery whether a merge's group still assembles (hq issue 525)

A merge from any head waited for the window because the controller could not
see a group's members, so the window skip changed nothing in production and
unrelated merges walked one after another. The controller now asks
mesh-delivery's groups, within 3 s and before the plans are held: a merge
waits only when its head's group has another member whose pull request is
open and whose merge it does not keep yet (ADR 0306 §2). No answer means it
waits, and its batch says why. A headed merge in no waiting group and related
to no batch is cut at once, as one from no head is (ADR 0304 §1, ADR 0306 §3).

The controller's grant names mesh-delivery.groups. The installer's first user
list in mesh-host must carry it too before the genesis test can pass.

internal/inventory/plans.go

@@ -122,6 +122,9 @@ type PlanBatch struct {
 	// decision 1, ADR 0306 decisions 2 and 3). A merge that joins it later opens its window again. It is not
 	// Closed, which is a stop's.
 	CutAtOnce bool `json:"cut_at_once,omitempty"`
+	// Waits says why a batch made for one merge waits for the window: its delivery group has a member still to
+	// merge, or mesh-delivery could not say whether it has (novox/hq ADR 0306 decision 2).
+	Waits string `json:"waits,omitempty"`
 }
 
 // OwnPath says the record is a batch of merges on the controller's own path.