What Does This Do

Changes CI test sharding from per-project to per-task granularity.

Previously, the -Pslot=X/Y filter was evaluated once per project via Project.isInSelectedSlot: every Test task
in a module (e.g. jdbc's test / forkedTest / oldH2Test / oldPostgresTest) was pinned to the same slot and
serialized inside one job. Now each test variant is hashed independently on the key "<projectPath>:<taskName>", so
a module's variants spread across different CI slots.

Key changes in CIJobsExtensions.kt:

• Task.isInSelectedSlot shards at task granularity; Project.isInSelectedSlot is kept for whole-project aggregates
  like runMuzzle.
• createRootTask now depends directly on the in-slot Test tasks the umbrella would run (via testTaskFilter),
  instead of gating with onlyIf against a project-level slot. Out-of-slot modules aren't pulled into the job at all.
• Slot parsing is centralized and cached once per build on the root project (SlotSelection / SlotHolder).
• Modules that collect coverage (-PcheckCoverage or a forceCoverage aggregate -> coverageEnabled) deliberately *
  fall back to whole-project slotting*, and the check/JaCoCo aggregate stays project-level (
  testTaskFilter = null). This keeps per-module JaCoCo execution data complete.

Motivation

The pipeline is gated by the slowest test_inst shard. Serializing all of a module's test variants in one job made that
shard taller than it needed to be. Sharding per task rebalances the work.

A/B comparison of two full pipelines on identical code (only the CI logic differs):

The slowest shard drops ~368 s and the pipeline wall-clock follows almost exactly — ~4 minutes faster (−7.6 %) while
using less total compute.

Additional Notes

⚠️ The old partitioning was silently skipping tests — this fixes it

While A/B testing, the pipeline's own aggregate_test_counts job revealed the old per-project logic was not running
every test:

The gap is entirely in core modules that have multiple test tasks per module:

Root cause. The old onlyIf gated each task on abs(project.path.hashCode() % totalSlots) + 1 == selectedSlot, but
totalSlots (the hash divisor) did not match the number of splits a job kind actually launched. Confirmed in a baseline
test_profiling job: it ran with CI_NODE_INDEX=3, CI_NODE_TOTAL=13, so the hash produced buckets 1..13 while the
job only ran selected=3 — no profiling module hashed to bucket 3, so 0 profiling tests ran. The baseline pipeline
even emitted its own ⚠️ WARNING: 6 job(s) with zero tests. The same misalignment skipped ~57 % of test_base (
6,610 -> 15,268 tests per JVM, same modules).

Why it's now covered. Per-task sharding hashes on "<projectPath>:<taskName>", and — more importantly —
createRootTask makes each aggregate depend directly on the Test tasks selected for its own slot rather than
relying on an onlyIf compared against a globally-numbered slot that didn't line up. Every test task now lands in
exactly one slot that actually runs.

Why this isn't double-counting. test_inst, test_inst_latest, and test_smoke are unchanged to within 0.06 %.
Those modules have ~one test task each, so they were never affected by the bug; if the new code ran anything twice, they
would inflate too. Only the multi-variant core modules gained tests — the signature of restored coverage, not duplicated
work.

Implemented and tested with Claude.