Add the pull-request check named format

[iderex]

Formatting arguments cost more than formatting. One formatter, one configuration
in the tree, and a check that refuses a diff.

There is a Windows-specific trap worth writing into the configuration now rather
than after somebody loses an afternoon to it. A formatter whose default line
ending is lf, run in a checkout made under core.autocrlf=true, reports every
tracked text file as failing on a tree with no modifications at all, and a real
formatting defect becomes indistinguishable from that noise.

Done when

A workflow exists whose check-run name is exactly format, it fails when the
formatter would change any tracked file, the configuration lives in the tree, and
a contributor on Windows running the documented command against a clean checkout
gets a clean result. Blocked on #99.

[iderex]

The Windows trap the body describes is no longer reachable through the checkout, and what this issue waits on has moved with it. Read at e5a513c23f9bc6a0ddedc7b52bb299ae5d0cee05.

The trap is a formatter defaulting to lf meeting a working tree translated to crlf by the clone. .gitattributes landed under #99 and pins the working-tree byte whatever a clone's own translation setting says. I ran the comparison rather than reading the rule, with translation switched on in the first clone:

git -c core.autocrlf=true  clone -q --branch main https://github.com/Flowfin/core on
git -c core.autocrlf=false clone -q --branch main https://github.com/Flowfin/core off
git -C on rev-parse HEAD
e5a513c23f9bc6a0ddedc7b52bb299ae5d0cee05
git -C on config --get core.autocrlf
true
tail -1 off/.gitattributes
* text=auto eol=lf
diff -rq --exclude=.git on off | wc -l
0
git -C off ls-files | wc -l
68

Sixty eight tracked paths and none of them differs, so a contributor who has core.autocrlf=true set globally gets the same bytes as one who does not, and a formatter defaulting to lf has nothing to disagree with.

Two things follow for the conditions here, and they run in opposite directions.

The configuration this issue asks to live in the tree does not have to carry a line-ending option to make the fourth condition true. The tree already holds the answer, in one place, for every path, and a second statement of it in a formatter's own configuration is a second thing that can be edited into disagreement with the first. Where the chosen formatter has such a setting, the useful thing it can do is refuse a carriage return rather than convert one, since converting hides the case where the byte arrived from somewhere other than the checkout.

The fourth condition still has to be checked once there is a formatter, and the reason is not the one in the body. A formatter can write a carriage return of its own on a machine whose platform default is crlf, and that is a defect the rule above does not touch: the rule governs what the checkout produces and what git records, not what a tool writes between the two. So the condition survives with its clean-checkout demonstration intact and its cause replaced.

What this issue waits on is therefore not #99. The half of #99 this issue's trap depended on has landed, and the halves still open there are a path rule for fixture directories and a test that reddens when it is removed, neither of which this issue's conditions read. What is left under all four conditions here is a formatter, which needs the toolchain in #11 and the commands in #13, and there is no build in this tree:

git ls-tree -r --name-only origin/main | grep -Ev '^(\.github/|docs/)'
.gitattributes
DCO
NOTICE.md
README.md

I have changed no condition and no scope.