[ixuz]

What and why

When the run has runners to spare, the check job is the last required job: npm run check:ci took 430–600 s when Turbo's cache missed, while the next jobs ended at about 300 s. Most of that is solid's test task, and most of that task was one file, solidDeckRepository.growth.test.ts. Vitest runs a file's tests one after another, so its growth tests ran in a row on one worker while the others sat idle. The round trip had the same problem: every release of the library in one file. This branch does what #562 proposes, in three commits.

• The growth tests are in four files, by what they write: solidDeckRepository.cards, .decks, .formats and .progress.growth.test.ts. The setup they share moves to src/testing/deckWrites.ts. All 14 tests keep their names, sizes and assertions. growth() compares the CPU time of the test's own process, so running the files on separate workers doesn't change what a test measures.
• The round trip is in four files, releaseDrafts.{1..4}.roundtrip.test.ts. The releases are dealt into them by the size of their Turtle, the largest first, each to the smallest file so far, so the large taxonomy and Solid Fundamentals versions are spread out. The dealing is deterministic and lives in src/testing/releaseShards.ts. Its test holds that every release is in exactly one shard, and that there is a file for each shard and no other, so no release is dropped or run twice.
• check:ci's parts are steps of their own in the check job: check:lints, check:tasks and check:repository, so the jobs API shows how long each takes. npm run check and check:ci call the same scripts, so a local run and CI run the same things. A later part still runs when an earlier part fails, so a run shows every failure, but none runs after npm ci or npm audit signatures fails.
• Docs: testing.md gives the check job's parts. Its conventions now say that a file of slow tests is split into files of about the same time, with their setup in src/testing/.

Closes: #562