docs: deepen cron-scheduler, content-pipeline, iac-pipeline, and disaster-recovery

Completes the full depth pass across all 16 docs - real tech names,
why-this-vs-the-alternative reasoning, heavy cross-linking between
every doc, ranked/specific tradeoffs instead of generic hedges.

docs/content-pipeline.md

@@ -1,7 +1,7 @@
 # 📝 Content Pipeline
 
 > [!WARNING]
-> Still under active development — this covers the current shape, not a finished architecture. Included deliberately rather than only showcasing finished work.
+> Still under active development — this covers the current shape, not a finished architecture. Included deliberately: a portfolio that only shows finished, polished systems doesn't show how something gets built, only how it ends up. This one's mid-build.
 
 ## The intended shape
 
@@ -12,30 +12,30 @@ flowchart LR
     Review --> Approved["Approved"]
     Approved --> Published["Published"]
 
-    Approved -.glue via automation tool.-> Storage["Draft/asset staging"]
-    Approved -.glue via automation tool.-> Blog["Published blog"]
-    Approved -.planned, not yet wired.-> Social["Social platforms"]
+    Approved -.glue via n8n.-> Storage["Nextcloud<br/>draft/asset staging"]
+    Approved -.glue via n8n.-> Blog["Ghost<br/>published blog"]
+    Approved -.planned, not yet wired.-> Social["Social platforms<br/>via Postiz"]
 ```
 
-A structured content tracker moves ideas through a status pipeline, with a workflow-automation tool gluing the stages together: approved content flows through to a file-storage staging area and out to a public blog. A separate, still-incomplete leg is meant to fan approved posts out to social platforms automatically.
+A NocoDB table tracks content ideas through a status pipeline, with n8n gluing the stages together — the same n8n instance mentioned in [`docs/orchestration.md`](orchestration.md)'s ecosystem, here doing content workflow instead of infrastructure maintenance. Approved content flows through to Nextcloud (draft/asset staging) and out to Ghost, a self-hosted blog. A separate, still-incomplete leg is meant to fan approved posts out to social platforms automatically via Postiz.
 
 ## A deliberate constraint, not a limitation stumbled into
 
 > [!TIP]
-> The social-publishing tool is **single-origin by design** — its frontend/backend URLs are baked to one specific public hostname at configuration time, so it deliberately has no presence in either internal DNS zone described in [`docs/dns-naming.md`](dns-naming.md); any other hostname hitting it fails CORS. This was a conscious choice, not a workaround: the tool is meant to be reached exactly one way.
+> Postiz is **single-origin by design** — its frontend/backend URLs are baked to one specific public hostname at configuration time, so it deliberately has no presence in either internal DNS zone described in [`docs/dns-naming.md`](dns-naming.md); any other hostname hitting it fails CORS. This mirrors the exact reasoning in [`docs/dns-naming.md`](dns-naming.md) for why genuinely public apps skip the internal zone model entirely: a social-publishing tool has no legitimate internal-only caller, so giving it internal DNS presence would just be attack surface with no corresponding benefit. This was a conscious choice, verified against Postiz's own architecture, not a workaround discovered after something broke.
 
 ## A real surprise in scale
 
 > [!IMPORTANT]
-> The social-publishing tool's real deployment footprint is 8 containers, not the app+database+cache most people would guess — it bundles its own workflow engine (mandatory for all of its background jobs, including scheduled posting itself) plus that engine's own database and search-based visibility store. A useful reminder that a tool's advertised simplicity and its actual operational footprint can be very different things.
+> Postiz's real deployment footprint is 8 containers, not the app+database+cache most people would guess from its marketing page — it bundles its own Temporal workflow engine (mandatory as of Postiz v2.12.0 for all background jobs, including scheduled posting itself, not an optional add-on) plus that engine's own Postgres database and Elasticsearch-based visibility store. Provisioning this stack meant sizing for 8 containers' worth of resource overhead, not the 3 the app's own documentation implies at a glance — a useful reminder, worth stating plainly, that a tool's advertised simplicity and its actual operational footprint on the host running [`docs/iac-pipeline.md`](iac-pipeline.md)'s hardened images can be very different things, and that finding out matters before capacity planning, not after.
 
 ## What's actually built vs. what's still wiring up
 
 | Piece | Status |
 |---|---|
-| Content tracker → automation → draft storage → blog | Most built-out, working end to end |
+| NocoDB → n8n → Nextcloud/Ghost | Most built-out, working end to end |
 | AI-assisted drafting step | Still being wired up |
-| Social-publishing fan-out | Still being wired up |
+| Social-publishing fan-out via Postiz | Still being wired up — see the notification-routing gap in [`docs/notifications.md`](notifications.md), which also hasn't caught up to this app yet |
 
 ---
-Related stacks: [`stacks/productivity/postiz/`](../stacks/productivity/postiz/), [`stacks/productivity/nocodb-content/`](../stacks/productivity/nocodb-content/), [`stacks/productivity/ghost/`](../stacks/productivity/ghost/)
+Related: [`docs/dns-naming.md`](dns-naming.md), [`docs/orchestration.md`](orchestration.md), [`docs/notifications.md`](notifications.md) · Stacks: [`stacks/productivity/postiz/`](../stacks/productivity/postiz/), [`stacks/productivity/nocodb-content/`](../stacks/productivity/nocodb-content/), [`stacks/productivity/ghost/`](../stacks/productivity/ghost/)