orchestration: fix major mischaracterization - only 1 of 13 flows has a human gate

Live-checked every flow's actual Kestra definition for a Pause task.
Only app-update has one; the other 6 main flows (os-update-vms,
container-update, disk-cleanup, os-update-pbs, os-update-pve,
os-update-pve-verify) run fully automatically with no human checkpoint
at all - their safety net is the automated health-check/rollback path,
not human approval. The doc previously presented check->pause->approve
as the universal pattern for all 13 flows and stated outright that
'nothing gets changed on the fleet without a human explicitly resuming
a paused flow', which was false for the flows that actually change
the fleet. The KB was already correct on this point.

Also replaced the mermaid diagram (broke this repo's established
Nextcloud-SVG convention) with a real diagram showing both patterns,
plus live evidence of the Pause-task check itself.

assets/orchestration-flow-patterns.svg

@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than draw.io -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" style="background: transparent; background-color: transparent; color-scheme: light dark;" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="1142px" height="642px" viewBox="0 0 1142 642" content="&lt;mxfile host=&quot;embed.diagrams.net&quot; scale=&quot;1&quot; border=&quot;0&quot;&gt;&#10;  &lt;diagram name=&quot;Flow Patterns&quot; id=&quot;orch-patterns-1&quot;&gt;&#10;    &lt;mxGraphModel dx=&quot;1414&quot; dy=&quot;791&quot; grid=&quot;1&quot; gridSize=&quot;10&quot; guides=&quot;1&quot; tooltips=&quot;1&quot; connect=&quot;1&quot; arrows=&quot;1&quot; fold=&quot;1&quot; page=&quot;1&quot; pageScale=&quot;1&quot; pageWidth=&quot;1200&quot; pageHeight=&quot;640&quot; math=&quot;0&quot; shadow=&quot;0&quot;&gt;&#10;      &lt;root&gt;&#10;        &lt;mxCell id=&quot;0&quot; /&gt;&#10;        &lt;mxCell id=&quot;1&quot; parent=&quot;0&quot; /&gt;&#10;        &lt;mxCell id=&quot;lane1&quot; parent=&quot;1&quot; style=&quot;swimlane;whiteSpace=wrap;html=1;startSize=30;fillColor=none;strokeColor=#6c8ebf;dashed=1;fontSize=13;fontStyle=1;fontColor=#333333;align=left;spacingLeft=8;verticalAlign=middle;&quot; value=&quot;12 OF 13 FLOWS — no human gate&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;140&quot; width=&quot;1140&quot; x=&quot;30&quot; y=&quot;30&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;l1s&quot; parent=&quot;lane1&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontColor=#333333;fontSize=12;fontStyle=1;shadow=1;&quot; value=&quot;Weekly / scheduled trigger&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;60&quot; width=&quot;220&quot; x=&quot;40&quot; y=&quot;50&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;l1r&quot; parent=&quot;lane1&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontColor=#333333;fontSize=12;fontStyle=1;shadow=1;&quot; value=&quot;Runs the playbook directly&amp;lt;br&amp;gt;&amp;lt;font style=&amp;quot;font-size: 10px;&amp;quot;&amp;gt;os-update-vms, container-update, disk-cleanup, os-update-pbs, dashy-fleet-audit, and 7 more&amp;lt;/font&amp;gt;&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;70&quot; width=&quot;420&quot; x=&quot;360&quot; y=&quot;45&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;l1n&quot; parent=&quot;lane1&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontColor=#333333;fontSize=12;fontStyle=1;shadow=1;&quot; value=&quot;Notify: succeeded / failed&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;60&quot; width=&quot;220&quot; x=&quot;880&quot; y=&quot;50&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;e1&quot; edge=&quot;1&quot; parent=&quot;lane1&quot; source=&quot;l1s&quot; style=&quot;html=1;endArrow=block;strokeColor=#6c8ebf;strokeWidth=2;rounded=1;&quot; target=&quot;l1r&quot;&gt;&#10;          &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;e2&quot; edge=&quot;1&quot; parent=&quot;lane1&quot; source=&quot;l1r&quot; style=&quot;html=1;endArrow=block;strokeColor=#6c8ebf;strokeWidth=2;rounded=1;&quot; target=&quot;l1n&quot;&gt;&#10;          &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;lane2&quot; parent=&quot;1&quot; style=&quot;swimlane;whiteSpace=wrap;html=1;startSize=30;fillColor=none;strokeColor=#d79b00;dashed=1;fontSize=13;fontStyle=1;fontColor=#333333;align=left;spacingLeft=8;verticalAlign=middle;&quot; value=&quot;1 OF 13 FLOWS (app-update) — check → pause → human approval → apply&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;480&quot; width=&quot;1140&quot; x=&quot;30&quot; y=&quot;190&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;l2s&quot; parent=&quot;lane2&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;fillColor=#ffe6cc;strokeColor=#d79b00;fontColor=#333333;fontSize=12;fontStyle=1;shadow=1;&quot; value=&quot;Weekly schedule&quot; vertex=&quot;1&quot;&gt;&#10;          &lt;mxGeometry height=&quot;60&quot; width=&quot;180&quot; x=&quot;40&quot; y=&quot;40&quot; as=&quot;geometry&quot; /&gt;&#10;        &lt;/mxCell&gt;&#10;        &lt;mxCell id=&quot;l2c&quot; parent=&quot;lane2&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;fillColor=#ffe6cc;strokeColor=#d79b00;fontColor=#333333;fontSize=12;fontStyle=1;shadow=1;&quot; value=&quot;Check mode run&amp;lt;br&amp;gt;&amp;lt;font style=&amp;quot;font-size: 10px;&amp;quot;&amp;gt;detect pending Vault/Technitium/Alloy updates&amp;lt;/font&amp;gt;&quot; vertex=&quot;1&quot;&gt;&#10Line truncated

docs/orchestration.md

@@ -1,28 +1,33 @@
 # 🔁 Orchestration
 
 > [!NOTE]
-> Kestra runs every scheduled maintenance flow across the fleet — 13 flows covering OS updates, container updates, app updates, disk cleanup, and KB self-maintenance — built around a check → pause → human approval → apply pattern rather than blind automatic changes. This is the layer that actually *acts* on the fleet, which is why it's the most tightly gated system in this repo.
+> Kestra runs every scheduled maintenance flow across the fleet — 13 flows covering OS updates, container updates, app updates, disk cleanup, and KB self-maintenance. Most run straight through on their own schedule with nobody watching; exactly one is built around a check → pause → human approval → apply pattern instead, reserved specifically for the one category of change judged worth a checkpoint.
 
-## Why a human-gated pattern instead of full automation
+## Why only one flow gets a human gate
 
-Fully automatic updates were the obvious simpler design, and they were rejected specifically because the cost of a bad automatic change (a broken update applied fleet-wide at 2am with nobody watching) is higher than the cost of a delayed one. The check → pause → approve pattern below trades speed for a human checkpoint at exactly the moment something is about to actually change — cheap insurance against the failure mode that matters most in a system with no on-call rotation behind it.
+A blanket human-gate policy was the obvious simpler design, and it was rejected: most of what these flows do — OS patching, container rebuilds, disk cleanup — already has its own automated safety net (the health-check/rollback path in [`docs/registry-and-build.md`](registry-and-build.md)), so a checkpoint on top of that would just be friction with nothing real behind it. The one flow that applies non-Docker infrastructure updates — Vault, Technitium, Alloy — is different: it draws the line at exactly the same place internally, auto-applying its own low-risk, self-contained piece without a gate and pausing only for the higher-stakes core-infrastructure changes. The pattern isn't "automation is risky, add a human" everywhere — it's a human checkpoint placed specifically where the risk profile actually warrants one, and left out everywhere it doesn't.
 
-## The core pattern
+## Two patterns, not one
+
+![12 of 13 flows run straight through on schedule with no human gate, relying on the automated health-check/rollback path instead; the one flow applying Vault/Technitium/Alloy updates runs a check-mode pass, pauses indefinitely on anything pending, and only applies after explicit human approval](../assets/orchestration-flow-patterns.svg)
+
+Nothing changes on Vault, Technitium, or Alloy without a human explicitly resuming a paused flow — a check run can sit paused for days until someone's actually available to review it, and that's treated as acceptable, not as a workflow to be optimized away. Every other flow's safety net is automated rollback, not a person watching. Every notification in this pattern routes through the shared pipeline in [`docs/notifications.md`](notifications.md), so a pending-approval flow shows up in the same place as every other alert.
+
+This is the real check, not an assumption — every flow's own definition, queried directly for a pause step:
 
-```mermaid
-flowchart LR
-    Schedule["Weekly schedule"] --> Check["Check mode run<br/>detect pending updates"]
-    Check --> Found{"Anything<br/>pending?"}
-    Found -->|no| NotifyClean["Notify: up to date"]
-    Found -->|yes| NotifyPending["Notify: pending"]
-    NotifyPending --> Pause["Pause<br/>indefinite, no timeout"]
-    Pause --> Decide{"Human<br/>resumes"}
-    Decide -->|approve| Apply["Apply mode run"]
-    Decide -->|decline| Skip["Skipped this cycle"]
-    Apply --> NotifyResult["Notify: applied / failed"]
 ```
-
+$ for flow in os-update-vms os-update-pve os-update-pve-verify os-update-pbs \
-Nothing gets changed on the fleet without a human explicitly resuming a paused flow — a check run can sit paused for days until someone's actually available to review it, and that's treated as acceptable, not as a workflow to be optimized away. Every notification in this pattern routes through the shared pipeline in [`docs/notifications.md`](notifications.md), so a pending-approval flow shows up in the same place as every other alert.
+              container-update disk-cleanup app-update; do
+    echo "$flow: $(curl -s .../flows/homelab/$flow | grep -c 'core.flow.Pause')"
+  done
+os-update-vms: 0
+os-update-pve: 0
+os-update-pve-verify: 0
+os-update-pbs: 0
+container-update: 0
+disk-cleanup: 0
+app-update: 1
+```
 
 ## Identity split, per flow