Attempt to work around migration spec failures by increasing parallelism

What does this MR do?

This is something of a shot in the dark. I suspect that if we get too many spec/migration specs in a single rspec unit job on CI, then the repeated migration runs and rollbacks cause us to hit the hard-coded 1600 column limit in postgresql. Not fun.

The distribution of migration specs across the jobs is effectively random. On average, with 20 jobs, we expect 5.55 migration spec files per job. I've observed reliable failures with 15 files that got allocated to one job by chance.

Increasing the number of jobs by 25% means our average is 4.44 files/job, rather than 5.5, reducing the chance of a pile-up. If we assume a normal distribution, that moves the probability from (mumble) to (mumble). More than 20%, but I can't calculate it off the top of my head.

This is not a fix for the overall problem, just a short-term attempt to reduce the number of cases of red master. We still need to decide on an actual fix.

Related to #63825 (closed)