"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

The underlying reason seems to be a substantial difference in the hosted
runners that execute these Dockerized jobs: forcing the PID limit of the
container to a high number lets the jobs pass, even when running the
complete matrix of all 13 Dockerized jobs concurrently.

Is the "reduce" in the title accurate?  The above description tells
me that what you did was to "raise" the PID limit (i.e., forcing the
PID limit to a high number), presumably because the default PID
limit is way too low for the tests to pass?

And that fix turns constant failures into success (albeit the tests
run very slowly, which is a separate topic that you discuss next).

But that's not
the only difference: The jobs seem to take a lot longer in these
containers than, say, in the containers made available to
https://github.com/git/git.

When forcing a PID limit of 64k in that private repository, the jobs
completed successfully, but they also took a lot longer, between 2x to
2.5x longer, i.e. painfully much longer. Reducing the PID limit to 16k,
the CI jobs still passed, but took an equally long amount of time.
Reducing the PID limit to 8k caused the errors to reappear.
...
It does not look as if the PID limit is the reason for the longer
runtime, seeing as the 64k vs 16k timings deviate no more than as is
usual with GitHub workflows. So let's go for 16k.

So 8k is too low to make them pass, just like the default setting
(whatever it is), but 16k is sufficient, so this patch settles at
that number, which makes sense.