marketing/facebook: record why CI #856 went red (the runner, not the gates)

gates.yml #856 for b9073e8f reports Failure, but the gate entry point never ran:
"Set up job" took 11m54s (normally seconds) and passed, then every following
step failed at 0s with an empty log. No gate verdict exists in that run.

The gates ARE green at that commit: repo_gates.py --fast in a throwaway worktree
checked out at b9073e8f and placed BESIDE the sibling repos gives rc=0, all 18
OK. The worktree was removed; git worktree list shows only the main tree.

A first attempt at that check, run from /tmp, reported script-tests FAILED and
five INCONCLUSIVE gates purely because the siblings were not beside it. Recorded
so it is not mistaken for a real failure next time: a gate run at the wrong path
convicts the layout, not the commit.

Not claiming CI passed - it did not run. This commit re-triggers it.

REPORT-facebook-cover-r919.md

@@ -260,6 +260,34 @@ every capital above the 25 px floor (48, 45, 43 px).
 **Still unmeasured: the Facebook app.** Three views are now measured and they disagree with each other and
 with Meta's help page. The app is the fourth and the most used. R-919 stays **VERIFY** for that reason.
 
+## 13. CI run #856 went RED, and it is the runner, not the code (2026-10-09)
+
+`gates.yml` run **#856** for `b9073e8f` reports **Failure**. It is an infrastructure failure, and the
+evidence is in the shape of the job, not in any gate:
+
+- **„Set up job” took 11m54s** and passed. It normally takes seconds, and the whole run normally takes
+  about 4m40s.
+- **Every step after it failed at 0s with an empty log** — Fetch the pushed commit, Fetch the agent, Fetch
+  the controller CHANGELOG, Fetch the app catalog, Classify the push, Run the gate entry point, Alarm on
+  failure, Complete job. The gate entry point never ran, so no gate verdict exists in that run at all.
+- DooPlex was simultaneously running another session's agent 0.154.0 delivery, which is Docker-heavy;
+  resource contention on the runner is the likeliest cause. Not proven, so it is written as the likeliest
+  cause and not as the cause.
+
+**The gates themselves are green at that exact commit.** `python3 scripts/repo_gates.py --fast` was run in
+a throwaway worktree checked out at `b9073e8f` and placed **beside the sibling repos**
+(`/mnt/5_hdd/felhom.eu/git/felhom.eu-r919verify`, so `../felhom-agent`, `../felhom-controller` and
+`../app-catalog-felhom.eu` resolve the way CI arranges them): **rc = 0, all 18 gates OK**. The worktree was
+removed afterwards and `git worktree list` shows only the main tree.
+
+**A first attempt at that check was misleading and is recorded so the mistake is not repeated.** Run from
+`/tmp`, the same commit produced `script-tests FAILED` and five INCONCLUSIVE gates — entirely because the
+sibling repos were not beside it. A gate run at the wrong path is not a gate run; it convicts the layout,
+not the commit.
+
+**What is NOT claimed:** that CI passed. It did not run. This commit re-triggers it, and the next run's
+verdict is the one to read.
+
 ## 10. Teardown
 
 Nothing on any host, the hub or Facebook. The work ran in the two git working trees only; the throwaway