ci(rulesets): manage rulesets as code and require the existing checks

[jdwillmsen]

What

Adds .github/rulesets/ — exports of both live rulesets plus the apply.sh the other four repositories use — and requires the four status checks that already run on every pull request.

Why

This was the last of the five repositories keeping its branch rules only live. The other four keep them as reviewable JSON, so a rule change shows up in a diff. Here there was nothing in git to review, nothing to reapply after an accidental UI edit, and no record of the previous state.

It is also not low-stakes. This repository holds the reusable workflows every other repository calls by @main — security-scan.yml, verify-pr-signatures.yml, the release workflows — plus the org-wide gitleaks.toml. Its gates protect all five repos, and main had zero required checks: any pull request could merge with every scan and signature job red as long as it carried one approving review.

Commits

1. manage branch rulesets as code — faithful exports of the two live rulesets and apply.sh. No behaviour change; both apply as no-ops.
2. require the checks — adds required_status_checks to Baseline.

Split so the snapshot can be reviewed as a snapshot rather than read as part of the change.

Which checks, and why only these

scan / scan          scan / gitleaks
scan / binaries      signatures / signatures

All four are published by the github-actions app (integration_id: 15368), pinned so a same-named check from another app cannot satisfy the rule.

Trivy is deliberately excluded. It is published by the code-scanning app from a SARIF upload rather than by the workflow, so it can simply not appear — and a required check that never appears blocks the branch permanently with nothing red to fix.

Each context was traced to its workflow before being required. security-scan-self.yml and verify-pr-signatures-self.yml both trigger on a bare pull_request with no paths: filter. Two of the underlying jobs — binaries and signatures — do carry if: github.event_name == 'pull_request', which is safe: a guard toward pull_request always fires when required checks are evaluated. The fatal pattern is the inverse (== 'push'), which reports skipping on a pull request and would deadlock main.

strict_required_status_checks_policy is false, matching platform, infrastructure and deployments. With it on, every merge to main invalidates the checks on every other open pull request.

Verification

Export round-trips against the existing rulesets rather than recreating them:

$ ./apply.sh --dry-run
would PUT repos/jdwlabs/.github/rulesets/17653724  (Baseline from baseline.json)
would PUT repos/jdwlabs/.github/rulesets/17653722  (Branch Naming Convention from branch-naming-convention.json)
done: 2 ruleset file(s) processed for jdwlabs/.github

• branch-naming-convention.json is byte-identical to live after normalisation
• baseline.json differs from live only inside .rules, by exactly the added required_status_checks
• apply.sh differs from the deployments copy only in REPO (plus a corrected re-export hint)

Not included

required_signatures. Not added, deliberately. It would be inert here for the same reason it is inert elsewhere in the org: rebase-merge rebuilds every commit server-side and signs none of them, so the rule cannot enforce what it claims. Adding an enforcement that cannot enforce is worse than its absence, because it reads as covered.

After merge

apply.sh must be run by hand — there is no drift job, so merging this alone changes nothing live.