registry-and-build: add real evidence for the 36/41 count and mariadb-mirror mechanism

Step 5 re-audit. Both were verified live earlier this session but
never shown - the strategy breakdown backs the doc's own headline
stat directly, and the mariadb-latest entry proves the specific
shared-mirror mechanism rather than just describing it.

docs/registry-and-build.md

@@ -28,7 +28,15 @@ This is the real registry, not a claim about it — every one of these is a genu
 
 ## Deliberate holdouts
 
-Not every stack is on this pattern, and that's a decision, not an oversight — knowing when *not* to apply a pattern uniformly is as much a design skill as building the pattern in the first place:
+Not every stack is on this pattern, and that's a decision, not an oversight — knowing when *not* to apply a pattern uniformly is as much a design skill as building the pattern in the first place. This is the real breakdown, not a rounded estimate:
+
+```
+$ python3 -c "import yaml; d=yaml.safe_load(open('docker_stacks.yml'))['stacks']; ..."
+total: 41
+dockerfile     36
+pinned_manual   3
+latest          2
+```
 
 | Stack | Why it's held out |
 |---|---|
@@ -36,7 +44,18 @@ Not every stack is on this pattern, and that's a decision, not an oversight —
 | Kodi's own app image | Genuinely still a direct Docker Hub dependency — low enough stakes that the extra build step isn't worth it |
 | Nextcloud's own `nextcloud`/`euro-office` services | Pre-existing custom Dockerfiles, left as-is beyond adding `image:` references — its own db/redis still float on Docker Hub tags directly, a conscious "don't touch what already works" call |
 
-Two more things that look like holdouts but aren't: `docker-socket-proxy` and Kodi's own `mariadb` service both run on `strategy: latest`, but neither actually depends on Docker Hub at runtime — each floats a `:latest` pull against a small dedicated mirror stack (`docker-socket-proxy-mirror`, `mariadb-latest`) that *is* built in-fleet via the normal pattern. It's a deliberate variant for lightweight consumer containers: one real build feeds every stack that needs that base image, instead of each one maintaining its own near-identical Dockerfile.
+Two more things that look like holdouts but aren't: `docker-socket-proxy` and Kodi's own `mariadb` service both run on `strategy: latest`, but neither actually depends on Docker Hub at runtime — each floats a `:latest` pull against a small dedicated mirror stack (`docker-socket-proxy-mirror`, `mariadb-latest`) that *is* built in-fleet via the normal pattern. It's a deliberate variant for lightweight consumer containers: one real build feeds every stack that needs that base image, instead of each one maintaining its own near-identical Dockerfile. This is the real entry, not a description of the pattern:
+
+```
+$ grep -A6 "^  mariadb-latest:" docker_stacks.yml
+mariadb-latest:
+  strategy: dockerfile
+  upstream_image: lscr.io/linuxserver/mariadb:latest
+  notes: >-
+    Not a real database - nothing connects to it directly. Exists purely
+    to be built and pushed so every stack needing a MariaDB (bookstack,
+    firefly iii, kodi) pulls from our registry instead of Docker Hub.
+```
 
 ## Trigger discipline