Issue 108: the second door was attached to the wrong thing

Two things were treated as one. The mesh's own artifact store holds the store seat and is internal by
design — reached by name over the overlay, no accounts, ADR 0082. Serving a registry publicly is a
service the mesh can host: a module with its own name, accounts and storage, like anything else it
runs for somebody. The conversion this report was written beside gave the seat holder a second public
door over the same filesystem, which is neither.

Keeps the original issue whole — no garbage collection, and the settings a routine needs are not
enabled — drops the two-door complication, and sharpens one thing: deletion on the only door is
deletion on a door with no accounts, which the predecessor kept behind its authenticated one.

04-ISSUES/108-the-registry-has-no-garbage-collection-once-it-has-two-doors/00-report.md

@@ -8,6 +8,35 @@ amended-design:
 
 # 108 — The registry has no garbage collection, and two doors make it harder to add
 
+## 2026-09-26 — the second door was attached to the wrong thing
+
+*Left in the title and in the text below rather than rewritten, because the reasoning that assumed
+two doors is what a reader needs to see retracted.*
+
+Two separate things were treated as one. **The mesh's own artifact store holds the store seat**: it
+is internal, reached by name over the overlay, with no accounts, because being on that network is the
+permission ([ADR 0082](../../02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)).
+**Serving a registry publicly is a service the mesh can host** — a module with its own name, its own
+accounts and its own storage, like any other thing it runs for somebody. The conversion this report
+was written beside gave the seat-holding store a second, public, authenticated door over the same
+filesystem, which is neither of those: it is the internal store with an external face.
+
+That second door is not being built. A publicly served registry, if one is wanted, is a module beside
+the store rather than another way in to it, and it brings its own storage with it.
+
+What that leaves here:
+
+- **The complication in the title is gone.** One door means one registry process on the store's
+  filesystem, so the shared blob-descriptor cache and the deletion-cached-by-the-other-door problem
+  this report worried about do not arise at all.
+- **The original issue is untouched, and is the whole of it.** The mesh's registry has no garbage
+  collection, never had, and the settings a collection routine depends on are not enabled.
+- **One thing is sharpened rather than removed.** Enabling deletion on the only door enables it on a
+  door with no accounts, reachable by everything on the overlay. The predecessor kept deletion behind
+  its authenticated door — which it could, having one. So adding garbage collection now includes
+  deciding whether deletion is exposed on that door at all, or only ever performed by a routine the
+  mesh runs against its own store.
+
 ## What was observed
 
 Reviewing the conversion that gives the mesh's image registry its public, authenticated name,