Put the merge check back to pending before a recheck asks it (hq issue 305)

A recheck asks of the head the forge already judged, and the forge keeps
the newest status of each context on it. Nobody reset mesh/merge-gate or
mesh/repo-check, so the old green stood and branch protection would merge
on it while the fresh check ran; rechecked heads did turn red.

mesh-delivery's recheck now asks the forge's holder to set the gate, and
the repository check when the head holds one, to pending ("checking
again: <why>") before it asks the controller; a forge that cannot be told
refuses the recheck whole. The gitea holder takes pending, and only
pending, on the merge check's statuses by hand: no verdict, so issue 293
still holds.

modules/gitea/test/delivery.test.ts

@@ -55,5 +55,9 @@ test("one view per pull request, found by its marker; only the mesh's statuses",
   // The merge check's statuses are its verdict's alone: required by a branch, they are never set by hand.
   assert.throws(() => deliveryStatus("mesh/merge-gate", "success", "x"), /merge check's status/);
   assert.throws(() => deliveryStatus("mesh/repo-check", "warning", "x"), /merge check's status/);
+  assert.throws(() => deliveryStatus("mesh/merge-gate", "failure", "x"), /merge check's status/);
+  // Pending is no verdict: a recheck says it so the old verdict does not let the head merge meanwhile.
+  assert.equal(deliveryStatus("mesh/merge-gate", "pending", "checking again: main moved on").state, "pending");
+  assert.equal(deliveryStatus("mesh/repo-check", "pending", "checking again: main moved on").context, "mesh/repo-check");
   assert.equal(deliveryStatus("mesh/delivery", "success", "x", "javascript:alert(1)").target_url, undefined);
 });