ci: bake the two smoke sites at once instead of one after the other

[lens0021]

Stacked on #469. Review the top commit; the base merges first.

The reproducibility check bakes the docs site a second time and diffs it, and the two bakes were 209s of the smoke job's 321s. They are independent by construction, so they can run together.

The reason it pays is that a bake is mostly one process. Only the skin passes run beside each other, and even those are three on a four-core runner, so a second bake fills cores the first leaves idle rather than taking any from it.

Measured

Two containers pinned to four cores, the runner's count, on an image built from this PR's base:

	wall clock
one bake alone	118s
two, one after the other	257s
two at once, four cores between them	150s
two at once, two cores each	166s

150s is what landed: no cpu flags, both bakes left to size themselves as they do today. Capping each at two cores is slower, because that also halves the concurrency of the part which does parallelise.

An earlier run of this benchmark gave the concurrent case a spurious win by capping each container at four cores on a fourteen-core host. That is eight cores between them, and not a runner at all. Discarded.

Peak combined resident memory was 1 GiB against the runner's 16, with no OOM in either log. That was the risk worth measuring: two bakes at three skin passes each is six MediaWiki boots at once.

Output is byte-identical in every configuration above, which is the check itself agreeing.

The step's own shell

Each bake writes to its own log, because two live logs interleave into neither, and both are printed afterwards in collapsed groups.

Verified that a failure still fails the step: a bake pointed at a source directory that does not exist ends it non-zero, and the success path ends it zero. Ran the step's shell verbatim, not a paraphrase of it.

The source mount is read-only now that two containers share it, so neither can alter what the other is reading. Only wikven translate writes into src, and this is not that.

Refs #461.

On the nine minutes in the issue

Worth recording, since it changes what is left to do. #461 measured 535s wall clock on #458, dominated by binary at 467s. But binary is path-filtered and does not run on a pull request that only touches PHP. On #466, which did exactly that, all 21 checks started within two seconds of each other and smoke at 317s was the longest:

317s  smoke
186s  coverage
145s  phan (master)
 52s  phpunit (REL1_46)
 43s  docker-image

So a PHP-only pull request already goes green in about five and a half minutes, and smoke is the whole of its critical path. The nine minutes belongs to image-touching pull requests, where binary is the long pole and a separate question.

This PR and #471 take smoke after the two of them from 321s to roughly 190s.