sync_blocked_label.py

@@ -25,9 +25,21 @@ entry -- it substitutes a zero-value stub (`id: 0`, every other field blank or
 null, including `state: ""`), so `d.get("state") != "closed"` used to treat it
 as "open forever". That kept a cross-repo `Status/Blocked` from ever being
 removed (weblib-ci#11) and, worse, made the reconciler *reassert* the label
-after a human removed it by hand (weblib-archive#30, 2026-09-09): every 15
-minutes it re-ran the same "not closed" test against the same unreadable stub
-and put the label back. Treating "cannot tell" as its own outcome -- change
+after a human removed it by hand (weblib-archive#30, 2026-09-09): it re-ran the
+same "not closed" test against the same unreadable stub and put the label back.
+
+Which runs did that is worth stating precisely, because the obvious answer is
+wrong. It was **not** the every-15-minutes schedule. Scheduled and `issues`
+events run the workflow from the *default* branch, and weblib-archive's default
+branch is `main`, which still carries a stale pre-org-label-migration local copy
+at `tools/sync_blocked_label.py`. That copy resolves the label with
+`repos/{repo}/labels`, both repos now have **zero** repo-level labels (all 25
+are org-level), so it returns None and exits with "skipped: no 'Status/Blocked'
+label in this repo" — writing nothing, ever. Measured 2026-09-09: 377 scheduled
+plus 54 `issues` runs, all no-ops. The reassertions came from `pull_request` and
+`workflow_dispatch` runs on branches cut from `development`, which do consume
+this shared script. So the symptom appears on PR activity, not on a timer.
+See weblib-archive#70 and cfbypass#35 for the stale copies themselves. Treating "cannot tell" as its own outcome -- change
 nothing, log the issue number -- fixes both without guessing an answer the
 token cannot support. See `is_resolved()`.