ci(checklist-status): declare why this workflow discovers no check family

`scripts/pm/dispatch-gates.mjs` requires every PATHS-FILTERED workflow to
either discover a `check:` family or declare why it has none, and this one is
paths-filtered by its `pull_request:` trigger (filtered to itself, per the
maintainer's amendment). It ran neither: its only working step invokes
`pnpm gen:checklist-status`, a generator, so `extractCheckInvocations` found
nothing and `declaredNoCheckFamiliesReason` read null. One case of 1866 in
`dispatch-gates --self-test`, and it took the required `Lint & Repo Gates`
context with it.

⛔ The fix is the declaration the tool itself prescribes — the marker the
workflow CARRIES, read fresh on every run — and ⛔ not an exemption list in the
script, which is the second copy of a fact that this whole family exists to
retire. Three workflows in the tree already carry it in exactly this form.

The reason is not an apology: the paired `check:checklist-status` was
explicitly ruled out, staleness of this reading entry is tolerated rather than
gated, and publishing on a schedule is what that ruling left. ⛔ Nothing about
the schedule, the wiki publish or the job-summary mirror is touched.

⚠️ The declaration owns ONE line: a comment directly beneath it in the same
form is read as a CUT reason and refused by name, so the paragraph above it
says not to wrap it.

Measured on this head through the tool's own exported predicates: gaps for
this file [] (was ["checklist-status.yml"]), whole-tree gaps [] over 38
workflows of which 16 are paths-filtered, and the reason reads WHOLE.

Claude-Session: https://claude.ai/code/session_01AmH9bKvGoLjiY86Q4Z3og2
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.github/workflows/checklist-status.yml

@@ -46,6 +46,15 @@ name: Platform Checklist Status
 # loudly, which is the right direction, but it is avoidable by merging the
 # ledger PR first.
 
+# This workflow is paths-filtered (the `pull_request:` trigger below), so
+# `scripts/pm/dispatch-gates.mjs` requires it to discover a `check:` family or
+# say why it has none. It has none, and that is the maintainer's ruling rather
+# than an omission: the whole point of publishing on a schedule is that the
+# paired gate was refused. The declaration is the one line under this
+# paragraph — it owns that line alone, so ⛔ do not wrap its reason or write a
+# comment directly beneath it; a continuation line is read as a CUT reason and
+# refused by name.
+# dispatch-gates: no-check-families -- the only step that runs anything is `pnpm gen:checklist-status`, a GENERATOR that renders the wiki pages; a paired `check:checklist-status` was explicitly ruled out (staleness of this reading entry is tolerated, not gated), so no named local check family exists for this workflow to discover
 on:
   schedule:
     # Weekly, as ruled. The ledger moves at the pace of platform capabilities,