Remove Content Pipeline system from the public repo

Removed by request - it was the one unfinished system in the repo,
and it's the user's call on what represents them publicly. Removed
completely: the README section, docs/content-pipeline.md, and the
two stacks that only existed to back it (postiz, nocodb-content).
Fixed cross-links in dns-naming.md and firewall-and-network.md that
pointed at it (replaced the public-facing-app example with the
still-present Ghost blog), and notifications.md (dropped the
reference, also fixed a leftover 'documented rather than hidden'
phrase in the same paragraph). Stat strip and stack counts updated
(55->53 stacks, 16->15 systems).

docs/dns-naming.md

@@ -39,7 +39,7 @@ flowchart TD
 Most apps that need both human and machine access get **one hostname per zone** — same app, two different front doors, chosen by which zone the caller resolves it in. Not every app needs both: a purely internal API integration might only ever get the app-to-app hostname; an app nobody automates against might only get the browser-facing one. The two zones aren't kept in lockstep by policy — a periodic audit is what actually catches when they drift, not an assumption that they match.
 
 > [!TIP]
-> **The public exception, and why it's a real exception and not a bug**: one app in this fleet ([`docs/content-pipeline.md`](content-pipeline.md)'s social-publishing tool) is genuinely meant to be reached from the open internet, and its own frontend/backend URLs are baked in at configuration time to one specific public hostname. It has **zero presence in either internal zone** — not because it was forgotten, but because a third DNS entry pointing at an app that already has its own public-facing edge route would just be redundant, and the app itself would reject requests arriving under any other hostname anyway (CORS). Apps meant for the public internet skip the internal model entirely rather than being forced into it.
+> **The public exception, and why it's a real exception and not a bug**: a self-hosted blog in this fleet is genuinely meant to be reached from the open internet, routed through the edge firewall's own public reverse-proxy layer (see [`docs/firewall-and-network.md`](firewall-and-network.md)). It has **zero presence in either internal zone** — not because it was forgotten, but because a third DNS entry pointing at an app that already has its own public-facing edge route would just be redundant. Apps meant for the public internet skip the internal model entirely rather than being forced into it.
 
 ## DNS as an enforced boundary, not just a convenience