instant-sync: `FARM_DISPATCH_TOKEN` → `Bad credentials` across supervised repos (token refresh — owner action)

[hyperpolymath]

What

instant-sync.yml (present on most supervised repos) calls peter-evans/repository-dispatch
with token: ${{ secrets.FARM_DISPATCH_TOKEN }}. The dispatch step fails at the API call
with Bad credentials — the token is missing/expired/revoked or lacks dispatch scope.
Every supervised repo's Instant Sync workflow is red as a result.

Distinct from #362 (that is allowed_actions=selected with an empty allowlist →
parse-time startup_failure) and from the reusable-pin startup failures in standards#426.
This is a step-level 401 from a bad secret.

Owner action (this is a credential, not a code bug)

Per the estate's shared-fate doctrine the honest close is to stop and flag, not bodge:
refresh/replace FARM_DISPATCH_TOKEN (a PAT able to fire a repository_dispatch on the
target) and set it as the secret the workflow reads. One token refresh clears the whole
Instant Sync cohort.

Detection (re-derive; do not trust a stale count)

Run ci-watch.sh (main-health mode) and read the Instant Sync red list. 2026-07-18
snapshot: this was the single largest main-branch red cohort (~60 repos). Re-verify current
breadth before/after; spot-check a few Instant Sync runs green after the refresh.

Related owner-owned credential reds (same class, for context)

• boj-server-cartridges — SonarCloud "Build" HTTP 403 (token rejected; see
  standards#443) + Cloudflare Pages deploy (both CF secrets absent + DNS). Owner decided to
  KEEP both and fix the credential side; tracked in session memory.
• Push email notification / Mirror to Git Forges / GitHub Pages secret cohorts — likely
  same class; drill per-category before acting.

Refs: standards#426 (estate CI-red master cause), #362 (Actions-policy actuator — sibling
estate-red cause, different mechanism), #400 (instant-sync dispatch pattern / PAT gating),
standards#443 (Sonar).

Provenance: session aa0b2861, estate CI/CD cleanup campaign, 2026-07-17→20.