Make the forge module's readings of step-ended design lines, and home the reserved client in its seat's contract

Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ

03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md

@@ -30,7 +30,7 @@ decisions:
 One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
 [G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
 
-*§560 to §584 answer develop's fifth batch of questions (lead-47's input of 2026-11-11, after round 3 of the review
+*§560 to §586 answer develop's fifth batch of questions (lead-47's input of 2026-11-11, after round 3 of the review
 of [G-12](G-12-develop-answers-fourth.md) and [G-14](G-14-recovery-module-and-review.md)), the reviewers' round-3
 notes on §516 to §559, and the knowledge base's review of ADR 0672 (the recovery module). Six carry the operator's
 answers of 2026-11-11 at lead-47's terminal, each line saying so: §562 (the recovery module's move), §563 (a put-off
@@ -493,3 +493,37 @@ removed. A note that corrects a line of G-12 or G-14 is written in that line; he
   (manifest validator), both manifests of G's heads accepted with their old sections, and a template entry in either
   refused; the catalog's validation at G's heads refuses neither; the delivery plan of G puts the grants part's
   delivery before both builds.
+- §585 **What the forge module reads from `step-ended`, and the form of its `failed-steps`.** (§39, §475, §487, §581)
+  The forge module's readings where no line spoke, made design lines:
+  - **The fingerprint** of a step is the body's `fingerprint`, the build-input fingerprint, which the runner fills
+    in every `step-ended`. No field of the step's `result` is read for it, and a `step-ended` without it is written in
+    the forge module's journal and changes nothing.
+  - **A failure** is a `step-ended` whose `outcome` is `failed` and whose `status` is `required`. An `optional` or
+    `bypass` step's failure, and a `could not run`, record no failure, as ADR 0666 §11 refuses only a failed
+    `required` step.
+  - **A rerun's pass** clears a failure when the body says `rerun: true` and its `by`, the caller the runtime proved
+    as the runner's verb `rerun` names its callers, is `operator` or `seat:mesh-healers`; any other `by` clears
+    nothing (§39).
+  - **The watched branches** are those of each registration whose git origin is a repository the forge holds, per
+    repository, read through `mesh-catalog`'s `registrations` and kept current on `registration-changed`.
+  - **A `seen` key** `seen.<commit>.<module>` holds `{v, commit, module, fingerprints, at}`: `v` the form's version
+    (1), `fingerprints` every build-input fingerprint the runs named for that commit and module, and `at` as §581
+    has it. Both key forms of `failed-steps` are defined in the seat `git`'s contract, in the forge module's
+    contracts package.
+  - **The fill** of `failed-steps` that its read tool shows is counted by the forge module from the keys and value
+    bytes it reads, against the state's cap of 64 MiB, and said as counted, since a bundle's state call gives no
+    fill of the bus's own.
+
+  Why: the forge module's developer read these where no line spoke (develop, batch 5); each follows §39, §475, §487
+  and ADR 0666 §11. How it is checked: unit (forge module), a `required` failure recorded and an `optional` one not;
+  a rerun pass by `operator` clears and one by another caller does not; a `seen` value read in its form; unit (the
+  seat `git`'s contract), both key forms read.
+- §586 **The client of `reserved` is the seat `mesh-builds`' contract package.** (§381, §478, §582) The forge
+  module's package registry and the image registry module both ask `reserved`. The call is the seat `mesh-builds`'
+  contract, so its client lives where ADR 0573 §1 puts a seat's contract: the package the seat's holder's
+  repository publishes, mesh-delivery's contracts package, which defines `mesh-builds` (§52). That package gains a
+  `mesh-builds` client with `reserved`, its input and its answers (`reserved`, `released`, `error`), and both
+  registry holders use it in place of their own copies. It is not put in mesh-sdk, which keeps no seat-specific
+  verb (ADR 0573 §1). Why: code two modules share has one home, and for a seat's verb that home is the seat's
+  contract package (develop question of the forge module's developer). How it is checked: unit (mesh-delivery's
+  contracts), the client's input and each answer read; the code review finds no second copy in either holder.

03-DESIGN/01-to-be/47-milestones/G.md

@@ -98,4 +98,4 @@ The part is fifteen files, each read whole, its design lines numbered across the
 - [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's answers of 2026-11-11 noon, round 3's leftovers and develop's fourth batch of questions (§516 to §553).
 - [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on).
 - [G-14-recovery-module-and-review](G-14-recovery-module-and-review.md): the recovery module, the operator's answer of 2026-11-11 12:55 CET, and the review of §516 to §553 (§554 to §559).
-- [G-15-develop-answers-fifth](G-15-develop-answers-fifth.md): develop's fifth batch, round 3's notes on §516 to §559, the knowledge base's review of the recovery module's record, and the operator's answers of 2026-11-11 about 14:05, 14:15 and 14:30 CET (§560 to §584).
+- [G-15-develop-answers-fifth](G-15-develop-answers-fifth.md): develop's fifth batch, round 3's notes on §516 to §559, the knowledge base's review of the recovery module's record, and the operator's answers of 2026-11-11 about 14:05, 14:15 and 14:30 CET (§560 to §586).