Require the gate's check names on main once they exist

[iderex]

The ruleset on main today protects against deletion and force-push and requires
a pull request:

gh api repos/Flowfin/core/rulesets/20572113 --jq '{enforcement, bypass: .bypass_actors, required: [.rules[].type]}'
{"bypass":[],"enforcement":"active","required":["deletion","non_fast_forward","pull_request"]}

There is no required_status_checks entry, so a pull request whose every check
is red can be merged, and a run that never happened leaves the same trace as one
that was green.

This issue is last in the milestone on purpose. Requiring a check name before the
check exists blocks every merge, and requiring a name that later gets renamed
detaches the requirement without any signal.

#113 decides which platforms the gate runs on, and that decides the shape of the
names required here. One leg per check leaves the names in #15 and #16 as they
are written. More than one leg turns each of them into one check run per
platform, so the strings this issue writes into the ruleset come from #113's
answer rather than from the single names those issues assume.

Done when

The ruleset on main carries a required_status_checks rule naming build,
test, lint, format, dependencies, and the checks the repository already
runs on pull requests, each by the literal check-run name that
gh api repos/Flowfin/core/commits/main/check-runs --jq '.check_runs[].name'
reports. A pull request with any one of them red cannot be merged. Blocked on
#15, #16, #17, #18, #19 and #113.

[iderex]

The ruleset paste above still reproduces, and the command the condition names to derive the check names from does not answer the question the condition asks.

The ruleset first, so the part that is unchanged is on the record:

gh api repos/Flowfin/core/rulesets/20572113 --jq '{enforcement, bypass: .bypass_actors, required: [.rules[].type]}'
{"bypass":[],"enforcement":"active","required":["deletion","non_fast_forward","pull_request"]}

The condition asks for the checks the repository already runs on pull requests, each by the literal check-run name that gh api repos/Flowfin/core/commits/main/check-runs reports. That command reads the default branch, and the default branch is not where those checks report:

gh api repos/Flowfin/core/commits/main/check-runs --jq '.check_runs[].name' | sort
Audit workflows (zizmor)
Reject Trojan Source Unicode
Scorecard analysis

Read against the head of a pull request instead, on fbc9db95bb040c312d5e0548ca5f7f2df6dbe20a:

gh api repos/Flowfin/core/commits/fbc9db95bb040c312d5e0548ca5f7f2df6dbe20a/check-runs --jq '.total_count'
9

gh api repos/Flowfin/core/commits/fbc9db95bb040c312d5e0548ca5f7f2df6dbe20a/check-runs --jq '.check_runs[].name' | sort
Audit workflows (zizmor)
DCO sign-off
dependency-review
Deterministic PR-hygiene checks
Documents name paths that resolve
External addresses in documents, reported and not gating
Reject Trojan Source Unicode
Reject Trojan Source Unicode
zizmor

Three things in that comparison bear on what this issue writes into the ruleset, and each one is a way to get the list wrong in a direction nobody would notice for a while.

Scorecard analysis reports on the default branch and not on a pull request head. Requiring it by name would leave every pull request waiting on a check that never arrives, which is the state this issue's own opening paragraph describes as pending rather than clean.

Six of the eight distinct names on that head do not appear on the default branch at all, so a list derived from the command as written omits most of what the condition is about, including the sign-off check.

Reject Trojan Source Unicode appears twice on one head, from two separate workflow runs, and zizmor appears beside Audit workflows (zizmor) from a different producer. So a check-run name is not a key here, and a required context has to be chosen knowing which producer answers for it.

The names are also not the workflow names. The listing of registered workflows recorded on #90 carries unicode-guard, Workflow Security Analysis and five others, and none of those strings is in the output above, so a list built from either one is wrong for the other.

The counts and the names move. I am recording the commands rather than asking for the output to be trusted later.