029 fixed — the store is added, not built, and the cycle is refused

The registry module names its image by digest, the way the bundle names
the three a first node starts from, and goes in as a manifest. The lab
now walks that path and passes.

A manifest that provides the store and also builds artifacts is refused
at parse. The lab had been passing only because its Docker Hub stand-in
quietly received the push — a prop covering for the thing under test.

04-ISSUES/029-the-artifact-store-cannot-be-delivered-by-the-artifact-store/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: open
+status: fixed
 opened: 2026-09-01
 located-in: [mesh-control]
-fixed-by:
+fixed-by: mesh-control be62f49; mesh-lab f85dbb0
 amended-design:
 ---
 
@@ -87,3 +87,18 @@ should be said out loud rather than discovered.
 A manifest that both provides `artifact-store` and declares built artifacts is refused where it is
 written, naming the cycle. Otherwise the fault surfaces as a build that never returns, on a mesh
 too new to have anybody watching it.
+
+## Fixed
+
+**The registry module names its image and is added, not built.** The lab's artifact-store test now
+walks the only path open to a real first mesh — the manifest goes in directly, no builder and no
+store involved — and passes.
+
+**And the cycle is refused where it is written.** A manifest that provides `artifact-store` and
+also declares built artifacts is refused at parse, naming the cycle: building publishes to the
+store, so it asks the mesh to put an artifact into the thing that artifact is needed to create.
+The provision name became a constant for the rule to turn on.
+
+What surfaced it in the lab is worth keeping: the test had always *built* the registry module and
+passed, because the scenario's stand-in for the public registry was standing there to receive the
+push. A prop that quietly covers for the thing under test is how a bootstrap hole stays invisible.