chore: permission catalog cannot be refreshed by consumer repos; no way to force an auto-group to evaluate #105

Two small gaps found while taking eqrm/ct-structure to production. Filing together because
neither is big enough alone; split if you'd rather.

1. A consumer repo cannot refresh the permission catalog

Every plan against eqrm.church.tools prints:

! Permission catalog was captured from ChurchTools 3.134.0 but this instance runs 3.135.2.
  Right names/authIds may be stale — regenerate it with `npm run regenerate:permission-catalog`

…but that script lives in this repo. A consumer repo has no way to act on the warning short of
opening a PR here and waiting for a release. So the warning is unactionable where it is printed,
and it prints on every single plan — which trains people to ignore it, including on the plans where
a stale authId would actually matter.

Options, roughly in order of appeal:

• Capture the catalog per instance at plan time and cache it in the consumer repo (e.g.
  .ct/permission-catalog.<host>.json, committed), falling back to the bundled one. The data comes
  from POST /index.php?q=churchauth/ajax func=getMasterData, which any authenticated session can
  call.
• Or ship a ct permissions catalog --refresh --env prod command that writes that file.
• Either way: only warn when a right the config actually uses is missing or has moved, rather
  than on any version delta.

Worth noting the stale catalog did not cause a wrong result in our case — the two authIds we
declared (102, 124) were read off live prod data — but that was luck plus paranoia, not design.

2. No way to make ChurchTools evaluate an auto-group now

ct apply writes the ruleset and flips the status; CT materializes membership on its own schedule.
So a freshly created auto-group is legitimately empty after a green apply, which reads as a
failure to anyone who doesn't know the model.

--refresh only covers dynamic groups changed in that run, so it cannot help you re-evaluate an
existing group, and it does nothing at all on a no-op plan. The actual lever is the legacy scheduler
ping:

curl -s -o /dev/null "https://<host>/?q=cron&standby=true"

That is what the admin UI's cron page hits (returns a 1×1 image, runs CT's due scheduled jobs). We
had to reverse it out of a HAR capture. Two things would close the gap:

• ct refresh --env prod [--group <key>] — POST /dynamicgroups/{id}/refresh for a named group
  regardless of whether it changed, and/or tick the scheduler.
• Document the distinction in the apply output itself: "ruleset written and activated; membership is
  materialized by ChurchTools on its own schedule."

The second is worth doing even without the first — the surprise is the expensive part, not the curl.