fix(ci): run release coverage in parallel and size it for the merge step

[howdu]

Problem

Run 30619680673 failed two ways in one step.

1. It ran serially. The workflow hand-rolls its own pest invocation so it can add --coverage-clover, and in doing so had drifted from the coverage composer script — it was missing --parallel. That put all 6115 tests through a single process: 3940s, pushing the job past an hour.

2. It then OOM'd anyway — after every test had passed:

PHP Fatal error:  Allowed memory size of 4294967296 bytes exhausted
(tried to allocate 1608519680 bytes)
in vendor/phpunit/php-code-coverage/src/Serialization/Serializer.php on line 108

Serial mode makes this worse in a non-obvious way: with one process there are no per-worker coverage sets, so the entire coverage graph accumulates in the runner and the Serializer's single largest allocation lands on top of an already-full 4G.

Changes

• Restore --parallel on the workflow's coverage command, plus the prepare / testbench optimize steps the coverage script runs before it.
• Raise phpunit-coverage.xml's limit 4G → 8G against the measured shortfall above, with the comment rewritten to cite it. That file is the sole owner of the limit — PHPUnit applies <php><ini> via ini_set() at bootstrap, after PHP has parsed the command line, so it silently overrides both -d memory_limit= and paratest's --passthru-php.
• Update CoverageWorkflowTest in lockstep, and add a guard pinning --parallel on both the workflow command and the coverage script — the two drifting apart is what caused this.

The root cause is duplication: the workflow re-implements a composer script. I couldn't collapse them (the workflow needs --coverage-clover and --stop-on-*), so the new test pins the one flag whose loss is catastrophic instead.

Verification

• composer preflight — green (phpstan, rector, pint, prettier, eslint, 6118 passed / 5 skipped).
• Smoke-tested --parallel --coverage-clover on tests/Unit: produced a valid merged clover spanning all 2413 source files, confirming clover survives the parallel merge.

Not verified: the full coverage job was not run locally, so 8G is sized from the crash's own numbers rather than a measured peak RSS of a successful parallel run. Parallel also shifts the profile — workers hold their own sets (~300MB each) and the parent merges them, so the parent peak should be lower than the serial case. The first green run on main is what confirms it.

🤖 Generated with Claude Code