capitalize headings

docs/registry-and-build.md

@@ -9,7 +9,7 @@
 | **Trigger** | Weekly schedule via Kestra, not push-triggered |
 | **Rollout** | All 5 Docker hosts converted; the largest has 36 of 41 stacks on this pattern |
 
-## Why self-host the registry instead of just using Docker Hub
+## Why Self-host The Registry Instead Of Just Using Docker Hub
 
 Pulling directly from Docker Hub/ghcr at runtime was the status quo before this existed, and it was replaced for a concrete reason: every container pull became a runtime dependency on an external service staying up and staying reachable through the firewall model in [`docs/firewall-and-network.md`](firewall-and-network.md). Building images in-fleet and pushing to a registry that's already inside the trust boundary means a redeploy never depends on an external registry's availability, and the exact image contents are fully within this fleet's own control rather than whatever an upstream maintainer pushed as `:latest` today.
 
@@ -19,14 +19,14 @@ This is the real registry, not a claim about it — every one of these is a genu
 
 ![Gitea's own package registry, filtered to container type — real self-built images including this fleet's own automation tooling, all private](../assets/registry-and-build-packages.png)
 
-## The cheap-check-first build decision
+## The Cheap-check-first Build Decision
 
 ![Every build starts with docker manifest inspect — metadata only, no pull — comparing the upstream image's digest against what's already in the fleet registry. If they match, nothing runs at all. If they differ, only then does it pull, build, compare image IDs, push what changed, and redeploy through the shared health-check/rollback path](../assets/registry-and-build-cheap-check.svg)
 
 > [!TIP]
 > Most stacks use a minimal `FROM <upstream-image>:${VERSION}` wrapper Dockerfile rather than a full clone-and-build-from-source setup — simpler, builds near-instantly, can't break from upstream build tooling changing underneath it, while still achieving the real goal: an in-fleet registry with no direct Docker Hub/ghcr dependency at runtime. A handful of multi-build-image stacks (the ones with more than one real upstream component, like Paperless-ngx, Ghost, Ollama, and the Grafana stack) skip the cheap check entirely, since a single "upstream digest" comparison doesn't make sense when there's more than one upstream involved.
 
-## Deliberate holdouts
+## 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. This is the real breakdown, not a rounded estimate:
 
@@ -57,7 +57,7 @@ mariadb-latest:
     firefly iii, kodi) pulls from our registry instead of Docker Hub.
 ```
 
-## Trigger discipline
+## Trigger Discipline
 
 > [!WARNING]
 > This is schedule-triggered, not push-triggered — a deliberate choice, not a missing feature. Editing a stack's own Dockerfile doesn't by itself trigger a rebuild; it waits for the next weekly sweep to find the upstream base image has actually changed, or for someone to force a manual run via [`docs/orchestration.md`](orchestration.md). The tradeoff: a simpler mental model and no rebuild storm on every unrelated commit, at the real cost of same-day propagation for an urgent base-image CVE fix — accepted because a weekly cadence matches this fleet's actual risk tolerance, not because push-triggering would have been harder to build.