docs: add orchestration, registry, dashy, cron, and content pipeline write-ups

Completes the orchestration/registry/content batch - Kestra's
check-pause-approve-apply pattern, the self-hosted build pipeline,
the SOC dashboard's 14-source aggregation, the cron heatmap, and the
in-progress content pipeline, all in the diagram+callout+table style.

docs/registry-and-build.md

@@ -0,0 +1,50 @@
+# 📦 Self-Hosted Registry & Build Pipeline
+
+> [!NOTE]
+> Docker images are built and hosted in-fleet rather than pulled from Docker Hub/ghcr directly — for every stack opted into this pattern, at runtime.
+
+| | |
+|---|---|
+| **Registry** | The Git server's own built-in container registry — no separate registry service to run |
+| **Trigger** | Weekly schedule, not push-triggered |
+| **Rollout** | All 5 Docker hosts converted; the largest has 36 of 41 stacks on this pattern |
+
+## The cheap-check-first build decision
+
+```mermaid
+flowchart TD
+    Start["Weekly trigger"] --> Check["Cheap digest check<br/>metadata only, no pull"]
+    Check --> Match{"Upstream digest ==<br/>fleet registry digest?"}
+    Match -->|yes| Nothing["Nothing runs<br/>no pull, no build, no push"]
+    Match -->|no| Pull["Pull base images"]
+    Pull --> Build["docker compose build --no-cache"]
+    Build --> Compare["Compare pre/post image IDs"]
+    Compare --> Push["Push what actually changed"]
+    Push --> Redeploy["Redeploy via shared<br/>health-check/rollback path"]
+```
+
+> [!TIP]
+> Most stacks use a minimal wrapper Dockerfile around the upstream image rather than a full clone-and-build-from-source setup — simpler, builds near-instantly, can't break from upstream build tooling, 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 skip the cheap check entirely, since a single "upstream digest" comparison doesn't make sense when there's more than one real upstream involved.
+
+## Deliberate holdouts
+
+Not every stack is on this pattern, and that's a decision, not an oversight:
+
+| Stack type | Why it's held out |
+|---|---|
+| Complex multi-service upstream builds | Not worth replicating a build process someone else already maintains well |
+| A docker-socket-proxy style stack | Simple enough that a custom build adds no value |
+| One database service still on `latest` | Deliberately not pinned to this pattern |
+| One stack with pre-existing custom Dockerfiles | Left as-is beyond adding image references — its own DB/cache still float on upstream tags directly |
+
+## Trigger discipline
+
+> [!WARNING]
+> This is schedule-triggered, not push-triggered. 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. A deliberate tradeoff: simpler mental model, avoids a rebuild storm on every unrelated commit, at the cost of same-day propagation for an urgent base-image CVE fix.
+
+## Housekeeping
+
+Unused local images get pruned automatically at the end of every build pass — for build-and-push-only stacks, the registry is the source of truth, not whatever happens to be sitting on local disk.
+
+---
+Related stacks: [`stacks/platform/gitea/`](../stacks/platform/gitea/), [`stacks/platform/kestra/`](../stacks/platform/kestra/)