CI: the code-coverage job's timeout-minutes is 30, tighter than the pl

[1-Bort-1]

CI: the code-coverage job's timeout-minutes is 30, tighter than the plain test job's 40, and it is the slower of the two

.github/workflows/CI.yml:76 gives test-with-code-coverage timeout-minutes: 30; .github/workflows/CI.yml:20 gives the plain test job 40. The coverage job runs the same suite under coverage instrumentation and then adds julia-processcoverage and a Codecov upload, so it is the one that needs the longer cap, not the shorter.

Seen on #285, same commit, two attempts of Julia 1.12 - ubuntu-latest - x64 - with code coverage:

• attempt 1: job 16m5s, julia-runtest 15m24s — inside the cap, and it reported a test failure (that one is test_forwarddiff.jl's POLAR_MATRICES check flakes at ~4%, and the oper #287).
• attempt 2: julia-runtest green (Testing VortexStepMethod... | 6304 passed, 1 broken, 0 failed, 10m06s), every step ticked through Complete job — and the job was cancelled at 30m1s with The job has exceeded the maximum execution time of 30m0s.

So the cap sits at roughly twice a warm run, and a cold julia-actions/cache@v2 restore tips it over. The failure it produces is indistinguishable at a glance from a real one: the check goes red with the suite entirely green.

For comparison, Julia 1.12 - ubuntu-latest - x64 - pull_request took 28m54s on the same commit under its 40-minute cap.

What I would do: raise test-with-code-coverage to at least 40 to match the plain job, or 50 given it is doing strictly more work. Separate from #279, which is about fail-fast: false in the same file.

[1-Bort-1]

Raising test-with-code-coverage's timeout-minutes in .github/workflows/CI.yml from 30 to 50, so the job doing strictly more work than the plain test job (40) is not the one with the tighter cap. Measuring the real job durations from recent CI runs first to justify the number. Leaving fail-fast (#279) alone.