[ixuz]

What and why

Since #530, the journeys jobs have started with the rest of the run and polled the jobs API until the site job was done. When several runs share the 20 runners, the site job waits in the queue too, often longer than its journeys jobs. Those jobs then hold five runners doing nothing, while other pull requests' jobs wait for one. In run 41785995461 they spent 2042 s waiting (34 runner-minutes), and in other busy runs 482–868 s. The overlap saves about a minute, but only when the run has runners to spare.

• The journeys jobs need the site job again (needs: [gate, site]). A failed site job skips them, and ci-ok already fails then. fail-fast-journeys fires only on a failure, so it doesn't fire on a skip. journeys-report still passes with no report, as it did before The journeys keep a run waiting 9–13 minutes and flash through every theme after each step #530.
• The "Wait for the site's build" step is gone, and with it the job's permissions: block. The block held only the workflow's default contents: read and the actions: read that the wait used.
• The timeout is 25 minutes again, the journeys' own time, as before 1f5c7a1. It no longer counts the site job's 30.
• The rest of The journeys keep a run waiting 9–13 minutes and flash through every theme after each step #530 stays: the Solid server still starts while the browsers are set up, and the shards, the axe checks and the tours are unchanged.
• Docs: testing.md says the journeys run once the site job is done.

The cost: when the run has runners to spare and check hits Turbo's cache, the journeys are the run's last jobs, and that run ends about a minute later. When check runs its tasks, it ends after the journeys anyway.

Closes: #561