Issue 319: record why no walk opened, and the four held deliveries closed with stop

A new module counts as something to move, so its delivery is held; a later walk
reaches only the delivery whose merge is its commit. Four covered deliveries were
stopped before this issue was found, and their merged pull requests now say error.

04-ISSUES/319-a-held-delivery-a-later-commit-superseded-has-no-end-but-release/01-diagnosis.md

@@ -46,3 +46,64 @@ Neither considers a held delivery whose content a later commit delivered.
 
 **Located** in mesh-delivery's state table (no end for a superseded or empty held delivery, and history
 read by how a delivery was made) and in to-be 47, whose state table carries the same gap.
+
+## 2026-10-09
+
+**Eleven held deliveries, read again.** On 2026-10-09 eleven deliveries were `held`, each raising D14's
+`delivery.<id>.stalled` and held for 24 to 48 hours. For each, `mesh-delivery.show` gave its state, why it was
+held, its merge commit and its plan. A fresh clone of the repository then showed whether the merge commit is an
+ancestor of the commit a finished walk delivered. `mesh-controller.status` listed none of the modules involved
+as behind. All eleven were covered: none held a change missing where it should run.
+
+**Why the controller opened no walk (open question 3).** This part comes from reading the code, and part of it
+is still a guess.
+
+- *A new module.* When a merge only adds a module, the controller's `SourceMoved`
+  (`cmd/mesh-controller/upgrades.go`) builds and registers it, sends it nowhere and opens no walk ("built,
+  registered when the build lands, and sent nowhere", issue 300). mesh-delivery's `MovesNothing()`
+  (`model.go`) counts `Plan.New` as something to move, though. So a delivery whose plan is "builds new: …, sent
+  nowhere" is not let through to `published` → `delivered`. Instead the unwalked rule in `holder.go` holds it
+  ten minutes after its merge: "merged, and the controller opened no walk for it within 10m0s". That is a fact
+  read from the code, and it matches `novox/mesh-catalog@60641176abaf`.
+- *The controller's own merges (a guess, not proved).* `SourceMoved` also returns without a plan in two cases:
+  when the modules the merge touches are "already built from it" (`already > 0`), and when the merge is read as
+  history (`isHistory`: merged before the source was last looked at). Either would leave a merge with no walk
+  of its own when another walk, or a person's push, had already built from a later commit. Which of the two hit
+  these merges is not yet known. The controller's journal for the minutes after each merge would say.
+- *The link from a walk to a delivery.* `deliveryWalking()` (`holder.go`) links a walk to the delivery whose
+  `merged_as` equals the walk's commit, and to no other delivery. A later walk that carried an earlier merge's
+  change therefore never reaches that earlier delivery, and nothing reads "this walk's commit contains your
+  merge". That is the missing input the first open question asks about. mesh-delivery could answer it from the
+  forge (is the merge commit an ancestor of the delivered walk's commit) together with the walk's moved modules,
+  without asking the controller what each machine runs.
+
+**Four were closed with `stop`, before this issue was found.** On 2026-10-09 the operator agreed to close the
+held deliveries. Four were stopped with why "covered: its merge … is contained in … which is delivered (walk …)":
+
+| delivery | merge | contained in | walk |
+|---|---|---|---|
+| `novox/mesh-controller@ec3769a8a669` | 099c176 | cec797e (the controller's main) | a finished three-tier walk of the controller |
+| `novox/mesh-controller@ea09f074db01` | e7dca6c | cec797e | the same walk |
+| `novox/mesh-controller@98ef7bac6e6a` | cdbbd9e | cec797e | the same walk |
+| `novox/mesh-catalog@60641176abaf` | 3da80a4 | a1406e7 (the catalogue's main) | a new module sent nowhere; a later finished catalogue walk |
+
+Their stalled conditions cleared at the next D14 observation. Open D14 conditions went from 11 to 7. As this
+issue already said, `stop` is the wrong record for them: their merged pull requests now carry `mesh/delivery`
+= error, "stopped: covered: …" (`effects.go`, `Stopped` → `error`). This blocks nothing, because they are
+merged. But the forge now records a delivered change as stopped, and a final state cannot be undone. The
+remaining seven were left `held` for this issue's fix.
+
+**The seven still held**, and why each is held:
+
+| delivery | why held | covered by | why it was not stopped |
+|---|---|---|---|
+| `novox/hq@055550802096` | merged without a passing check | merge on hq's main; builds nothing | held for a different reason than the controller's merges; builds nothing |
+| `novox/hq@2221be11a6ef` | merged without a passing check | merge on hq's main; builds nothing | the same |
+| `novox/hq@897bcce50252` | merged without a passing check | merge on hq's main; builds nothing | the same |
+| `novox/hq@ef6ab814b053` | merged without a passing check | merge on hq's main; builds nothing | the same |
+| `novox/mesh-controller@b98fd0f396c8` | no walk opened within ten minutes | 7f25666, contained in cec797e | a member of a group still `delivering` (2 of 3); `stop` stops the group's later members too |
+| `novox/mesh-controller@ea92af2a7d77` | no walk opened within ten minutes | 3808634, contained in cec797e | `show` lists a step still `judging` on the control-node, carried by a release walk that is done; the step looks stale but is not final |
+| `novox/mesh-catalog@66106d93accd` | its group's composed check did not pass for the heads that merged ([issue 316](../316-a-group-member-held-before-its-composed-check-answered-stayed-held-after-it-passed/00-report.md)) | 7cd989b, contained in a later finished walk of the same module | its group is still `delivering`, and its own walk is `superseded` |
+
+The seven show the two ends this issue asks for: four hold nothing to deliver, and three are covered by a
+later walk.