Epic: the API chain stops being the wall behind the frontend suite

[ExtraToast]

#1308 takes the frontend e2e job from 14 minutes to about 5. This epic is the other half: once e2e stops being the longest job, the API chain is what the run waits on.

Measured on run 35332899202, a green run on current main:

path	ends
fe-static → fe-e2e 18m04s	10:25:28
api-static 5m40s → api-tests 8m20s	10:22:51
api-static → build-images 4m33s → system-tests 4m44s	10:19:16

The whole run was 20m11s. Two paths finish within three minutes of each other, which is why #1308 alone does not move the pipeline number much.

What is already done

#1284 took the image build off the critical path: the system tests run the jar and the bundle natively, so nothing downstream waits for build-images any more. That work is not repeated here.

The decisions

• Split the test job before sharding it. Unit tests need no database; they were only slow because they shared a job with the integration suite.
• One sharding mechanism across the repo. :tests:system, the frontend e2e suite and now :services:api:integrationTest all partition by a stable hash of the test class, so there is one pattern to learn and a class always lands on the same shard.
• A shard gets its own database. The fixtures collide on unique fields, so maxParallelForks against a shared MariaDB was never an option. Six services is the cost of the split.
• The coverage floors do not weaken. ci(coverage): the floors are run, and the unit report reaches the artifact #1282 put real floors on this suite days ago. Sharding merges the execution data and measures the whole picture rather than lowering anything.
• Linting is not a gate on testing. ktlint and detekt are source-only and nothing waits on them.

Slices

• the API integration suite runs in six shards, and the floors read all six #1318 — the integration suite runs in six shards, and the floors read all six. Also carries the unit split and the lint split.
• one integration class is a fifth of the suite's runtime #1319 — one integration class is a fifth of the suite's runtime. The floor on what sharding can reach: RecoveryControllerEmailIT is 68.5s of shard 4's 114.2s.
• a sharded test task hides its shard number from Gradle's input hash #1320 — a sharded test task hides its shard number from Gradle's input hash. Latent in :tests:system today; the API integration suite runs in six shards, and the floors read all six #1318 fixes the shape for the API suite and this carries it across.

What is deliberately not here

• api-static's 4m13s compile-and-cache-warm step. It gates everything, so it is the next thing worth measuring, but nothing here touches it.
• Runner queueing. api-tests started 3m18s after its dependencies finished on the run above, and Epic: the frontend e2e job stops being a fourteen-minute wait #1308 plus the API integration suite runs in six shards, and the floors read all six #1318 together add up to twelve concurrent jobs. The plan is to measure the queue delay once both have landed and cap shard counts if the parallelism is not actually being served.