cron-scheduler: add real evidence for two 'what we found' claims

Step 5 re-pass under the strengthened evidence gate. Both the
app-update duration correction and the Authentik 404 finding were
narrative-only, backed by data I'd already verified live but never
actually shown. Added the real NocoDB row notes as evidence blocks.
Left the other three bullets as-is - the file already has 2 real
screenshots plus these 2 data blocks, judged sufficient rather than
padding every bullet for its own sake.

docs/cron-scheduler.md

@@ -31,9 +31,25 @@ Populating 50 rows by hand across a dozen-plus different systems wasn't just dat
 
 - **A three-way monthly collision, resolved by moving one job.** PBS's own datastore garbage-collection job used to run first-Saturday-of-month 02:00 — the same slot as the weekly `os-update-vms` Kestra flow *and* the `dashy-fleet-audit` flow, both of which also land on Saturday. Moved to first-Tuesday-of-month 10:00 instead, clearing all three out of each other's way in one change rather than shuffling the other two around it.
 - **A cascading reschedule, not an isolated fix.** Kopia's backup snapshot used to run 07:00 — directly on top of Proxmox hyper2's own fixed VM-backup slot (disk-intensive, kept fixed on purpose). Moving Kopia to 08:00 then put it on top of ClamAV's scan, so ClamAV moved again to 09:00 — one collision fix triggering a second, tracked and resolved rather than left half-done.
-- **Don't trust a duration number until it comes from a real completed run.** `app-update`'s first-logged duration was ~2-3 seconds — which turned out to be sampled from killed, failed, and paused runs, not a real completion. The actual number, from a genuine successful run, is ~16 minutes: an 8x difference between "what the data said" and "what actually happened," caught only by checking.
+- **Don't trust a duration number until it comes from a real completed run.** `app-update`'s first-logged duration was ~2-3 seconds — which turned out to be sampled from killed, failed, and paused runs, not a real completion. The actual number, from a genuine successful run, is ~16 minutes: an 8x difference between "what the data said" and "what actually happened," caught only by checking. This is the actual row note, not a paraphrase:
+
+  ```
+  $ curl -s -H "xc-token: [REDACTED]" ".../api/v2/tables/<cron-scheduler>/records" \
+    | jq -r '.list[] | select(."Job Name"=="app-update (Kestra)") | .Notes'
+  Duration corrected 2026-07-31: real successful completion took ~16min -
+  the earlier ~2-3s figure came from KILLED/FAILED/PAUSED runs, not a
+  real completion.
+  ```
 - **The heaviest job in the entire fleet isn't a backup.** Radarr's own `Refresh Movie` task runs ~1h15min daily — heavier than any single PVE backup job, and the heaviest scheduled task found anywhere in the *arr media suite. Radarr's own backup job, by contrast, finishes in about 41 seconds.
-- **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have.
+- **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have. Same live query, same real note:
+
+  ```
+  $ curl -s -H "xc-token: [REDACTED]" ".../api/v2/tables/<cron-scheduler>/records" \
+    | jq -r '.list[] | select(."Job Name"|test("Authentik")) | .Notes'
+  Resolved via GET /api/v3/tasks/schedules/ 2026-07-29 (endpoint moved
+  from the old /admin/system_tasks/ path in this Authentik version -
+  that's why the first attempt 404'd, not an auth problem).
+  ```
 
 ---
 Related: [`docs/orchestration.md`](orchestration.md), [`docs/disaster-recovery.md`](disaster-recovery.md), [`docs/dashy-soc-board.md`](dashy-soc-board.md) · Stacks: [`stacks/platform/dashy/`](../stacks/platform/dashy/), [`stacks/platform/nocodb/`](../stacks/platform/nocodb/)