docs: render architecture & flow diagrams as draw.io charts

Replace ASCII-art diagrams across the README and docs/ with editable
.drawio sources plus exported PNGs, so the diagrams render clearly in
rendered markdown and can be maintained/regenerated instead of being
hand-edited as fragile text art. Non-diagram blocks (code, folder
trees, UI wireframes) were left as text.

docs/requirements/Component-StoreAndForward.md

@@ -25,23 +25,8 @@ Site clusters only. The central cluster does not buffer messages.
 
 ## Message Lifecycle
 
-```
-Script submits message
-    │
-    ▼
-Attempt immediate delivery
-    │
-    ├── Success → Remove from buffer
-    │
-    └── Failure → Buffer message
-                    │
-                    ▼
-              Retry loop (per retry policy)
-                    │
-                    ├── Success → Remove from buffer + notify standby
-                    │
-                    └── Max retries exhausted → Park message
-```
+![storeforward-message-lifecycle](diagrams/storeforward-message-lifecycle.png)
+<!-- source: diagrams/storeforward-message-lifecycle.drawio — edit, then re-export with export-drawio.sh -->
 
 For notifications, "delivery" means forwarding the message to the central cluster via Central–Site Communication; "success" is central's ack, on which the message is cleared. Notifications are retried at the fixed forward interval until central acks, but — like every other category — they are bounded by the engine's `DefaultMaxRetries` cap: a sustained central outage that exceeds `DefaultMaxRetries × forward-interval` will park the buffered notification, after which an operator can Retry/Discard it via the parked-message UI. Operationally, the cap is sized so the normal central-recovery window stays well inside it; "do not park" is the design's operational intent on the happy path, not an absolute invariant. Callers that genuinely require unbounded retry pass `maxRetries: 0` on `EnqueueAsync` (the documented "no limit" escape hatch — see `StoreAndForward-015`).