[Phase 2] Extend release-channel-tags to ring channels + codify in apply-rulesets.sh

[don-petry]

Parent: #495 · Phase 2 · Work type: Infra · Targets SC3.

Follow-up to #505 (which delivered tag protection for pr-review/** and dev-lead/**). The canary rollout (#499/#500/#501) introduces per-ring channel tags that also need protection, and the existing ruleset is live-only.

What exists today

A tag ruleset release-channel-tags (id 17432201) is active on petry-projects/.github-private, targeting refs/tags/pr-review/** and refs/tags/dev-lead/**, restricting update + deletion, bypass actors = OrganizationAdmin + App 3167543. It is not present on petry-projects/.github, and exists only as a live GitHub object + docs — it is not codified as a committed rulesets/*.json and not deployed by scripts/apply-rulesets.sh (which today applies only the branch rulesets pr-quality / code-quality).

Gaps to close

1. Coverage — extend the ruleset's ref_name.include to protect the new ring channels (refs/tags/<name>/{next,ring0,ring1,stable} per reusable, or a tree-scoped pattern), and add the equivalent ruleset on petry-projects/.github.
2. Bypass = the promotion mover — bypass actors must include whatever identity moves channel tags (today GH_PAT_WORKFLOWS; if/when we switch to a dedicated GitHub App per [Phase 2] Replace PUT-contents clobber deploy with versioned, ring-staged, health-gated promotion #501, add that app id). The promotion workflow stays the sole authorized mover.
3. Codification — commit the ruleset as rulesets/*.json and teach scripts/apply-rulesets.sh to deploy it, so it's reproducible and reviewable rather than live-only.

Done when: ring channel tags on both org-infra repos are protected (update/deletion restricted, bypass = promotion mover only), and the ruleset is codified + applied via apply-rulesets.sh.

Decisions context: petry-projects/.github#516.

[github-actions]

Thanks for the detailed write-up and for linking the relevant context from #505 and #499–#501! Before moving forward with codification and the apply-rulesets.sh changes, could you confirm the intended glob pattern for ring channel tags — specifically whether protection should use a tree-scoped wildcard like refs/tags/<name>/** or the explicit four-suffix form refs/tags/<name>/{next,ring0,ring1,stable} as listed in the issue?