registry-and-build: fix mischaracterized holdouts, add the real mirror-stack pattern

Live-checked docker_stacks.yml directly. Total/dockerfile-strategy
counts (41/36) and the pinned_manual holdouts were already accurate.
But docker-socket-proxy and kodi's mariadb service were wrongly listed
as still hitting Docker Hub directly - both actually float a :latest
pull against a dedicated in-fleet mirror stack (docker-socket-proxy-
mirror, mariadb-latest) built via the normal dockerfile pattern. Fixed
the table and documented the real mechanism. Same gap existed in the
KB note, fixed there too.

docs/registry-and-build.md

@@ -33,10 +33,11 @@ Not every stack is on this pattern, and that's a decision, not an oversight —
 | Stack | Why it's held out |
 |---|---|
 | Authentik, Immich, tdarr | Complex multi-service upstream builds — not worth replicating a build process the upstream project already maintains well; the maintenance cost of tracking their own build changes would exceed the benefit |
-| docker-socket-proxy | Simple enough that a custom build adds no real value over the upstream image directly |
-| Kodi's mariadb service | Deliberately still on `latest`, unpinned — low enough stakes that the extra build step isn't worth it |
+| 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.
+
 ## Trigger discipline
 
 > [!WARNING]