apply-repo-settings: release cut + ring rollout (follow-up to #984 / PR #985)

[don-petry]

Tracking the release/rollout phases of #984 once PR #985 merges.

Sequence (order matters — a consumer stub pinned to a nonexistent tag = startup_failure):

1. Cut apply-repo-settings/v1.0.0 and seed the v1-next|v1-ring0|v1-ring1|v1-stable channel tags. canary-rollout.sh autocut (gated by CANARY_AUTO_CUT) should do this on the first scheduled tick after merge since the reusable is registered in standards/canary-rings.json; verify it does, or cut manually per docs/release/versioning.md.
2. Only then vendor the thin caller stub (standards/workflows/apply-repo-settings.yml) to ring members, each pinned to its ring's channel tag: next=.github-private, ring0=.github (already dogfoods via local ref), ring1=markets,TalkTerm,bmad-bgreat-suite, stable=everyone else.
3. Feed the Define the release soak standard (ring-promotion gate): time floor + traffic-scaled sample + health #548 gate: one workflow_dispatch per ring repo after its stub lands (weekly cron starves the sample floors — see the _cadence_note in the registry entry).
4. After stable: enable RING_REUSABLES enforcement for apply-repo-settings in scripts/lib/ring-pins.sh (deliberately deferred in PR feat: implement issue #984 — Standardize branch-policy compliance self-heal: vendor apply-repo-settings as a canary-ringed reusable #985), and close apply-repo-settings 100% fail: check-suites API needs classic-PAT/App admin (GH_PAT_WORKFLOWS rejected, 403) .github-private#1209 with evidence (gh api repos/<repo>/check-suites/preferences + green weekly runs).

Precondition (Phase 0 of #984, needs org admin): verify the GH_PAT_DON_PETRY org secret's visibility covers the whole fleet incl. public repos, and one PATCH check-suites/preferences → 200 capability probe.

Per-repo fork-deletion issues: filed in each affected repo, blocked on step 1–2 of this issue.