Issue 113 resolved by the repin, and what issue 064 did not cover

The object-store module was repinned to a maintained fork of the withdrawn server image, its
runtime sidecar built rather than pulled, and its data moved off the predecessor's live
directory. The instance is closed; the three general points the report makes are not, and What
was done says so rather than letting a resolved status imply otherwise.

Folds in the one thing a duplicate report of this symptom had that this one did not: issue 064
asked whether the build environment can reach a declared vendor image and assumed that, once
declared, it stays fetchable. Withdrawal is the case that assumption does not cover. The
duplicate is not merged — it carried the reading this report's diagnosis retracts.

04-ISSUES/113-the-object-stores-images-were-withdrawn-upstream/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-24
 located-in: [mesh-catalog modules/minio]
-fixed-by:
+fixed-by: mesh-catalog — the object-store module repinned to a maintained fork of the withdrawn server image, its runtime sidecar built from source rather than pulled, and its data moved off the predecessor's live directory. The standing condition this report names is not closed by it — see What was done.
 amended-design:
 ---
 
@@ -109,6 +109,28 @@ a registry the mesh does not control — **by tag or by digest, it makes no diff
 dependency with no guarantee behind it, and the mesh currently learns it has lost one only by
 trying to use it.
 
+[Issue 064](../064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md) is the
+nearest precedent, and it does not cover this. That issue asked whether the mesh's build
+environment can **reach** a declared vendor image — a network-policy question, answered by
+requiring the image be declared as a build input — and it assumed that an image, once declared,
+stays fetchable. Withdrawal is the case the assumption does not cover: no network policy and no
+declaration makes a deleted repository resolvable, so a module can satisfy 064 in full and still
+be unbuildable on a node that holds nothing.
+
+## What was done
+
+The module was repinned to a maintained fork of the server image, published to a registry that
+still serves it; its runtime sidecar is now built from source rather than pulled; and its data was
+moved off the predecessor's live directory. The object store runs on the control-node from that
+pin, and a node holding nothing can obtain it again.
+
+That answers the instance and none of the three points above. The mesh still cannot say which of
+its other pinned third-party images are still obtainable, and it would still learn of a withdrawal
+only when a node without the image tried to deploy. The replacement question — S3 the protocol
+rather than this product — is carried by
+[research 015](../../01-RESEARCH/015-the-object-store-after-minio/00-overview.md); the detection
+question is carried by nothing, and is the first of the open questions below.
+
 ## Open questions
 
 - Should the mesh **hold** the images it depends on — mirroring third-party images into its own