Manage repository rulesets as code

Summary

Check AX's repository rulesets into the repo, so ruleset changes are proposed, reviewed and audited as PRs instead of edited only in the GitHub UI.

Today, the rulesets on main can only be seen and changed by repo admins in Settings. Contributors can't see what is enforced, or why it changed.
The rest of this epic adds or changes several rulesets (merge queue, tag protection, release branches). Keeping them in code lets each change be reviewed with the CI and docs changes it depends on.
When the live configuration drifts from the intended one, nobody notices today. For example, CONTRIBUTING.md says approvals are dismissed after a push, but the ruleset doesn't do that.

Export each active ruleset to .github/rulesets/<name>.json with gh api repos/google/ax/rulesets/<id>. Remove server-managed fields such as id, node_id, _links, created_at, updated_at and source*, so the files contain only the policy: name, target, enforcement, conditions, rules, bypass_actors.
Apply with hack/apply-rulesets.sh, which a repo admin runs:
- Match local files to live rulesets by name.
- PUT /repos/google/ax/rulesets/<id> for existing rulesets, and POST /repos/google/ax/rulesets for new ones.
- Support --dry-run, which shows the differences without changing anything.
- Never delete live rulesets that have no file. List them instead.
Detect drift with a scheduled workflow, or a step in an existing one, that compares .github/rulesets/*.json with the live rulesets and fails or opens an issue when they differ.
- Reading rulesets needs a token that can see bypass_actors, which requires admin. Decide whether this check uses a GitHub App or token with admin read, or compares everything except bypass_actors.
Document the flow in CONTRIBUTING.md or docs/dev/rulesets.md. The flow is: open a PR that edits the JSON, get it reviewed, and after merge an admin runs hack/apply-rulesets.sh.

Every active ruleset on google/ax has a matching file in .github/rulesets/
hack/apply-rulesets.sh --dry-run reports no differences against the live configuration right after export
hack/apply-rulesets.sh creates or updates rulesets from the files, matched by name
Drift between the files and the live rulesets is reported automatically
The process for changing a ruleset is documented

Should applying stay a manual admin step, or eventually run automatically after merge using a GitHub App that has admin rights on rulesets?
Who are the admins who can run the apply script?

This issue is the foundation for the other rulesets work in this epic. Later sub-issues (stale-approval dismissal, merge queue, tag and release-branch protection) should each land as a JSON change in this directory.
Reference: GitHub REST API: repository rulesets.