a sharded test task hides its shard number from Gradle's input hash

[ExtraToast]

:tests:system shards its suite by reading SHARD_TOTAL / SHARD_INDEX and applying a --tests filter inside doFirst:

val shardTotal = System.getenv("SHARD_TOTAL")?.toIntOrNull()?.takeIf { it > 1 }
val shardIndex = System.getenv("SHARD_INDEX")?.toIntOrNull()
if (shardTotal != null && shardIndex != null && shardIndex in 1..shardTotal) {
    doFirst { /* ... filter { includeTestsMatching(it) } ... */ }
}

Gradle does not hash doFirst actions. The shard number reaches the task through the environment and through nothing Gradle records, so all six shards present identical task inputs. A Test task is cacheable, and CI runs with --build-cache and cache-read-only: false, so in principle one shard's result can be served to another as FROM-CACHE — six green shards where only one suite ever ran.

It has not been observed failing. The system tests take their stack from -D flags and a live compose stack, which may be keeping the entries apart in practice, and the run this was noticed on showed all six shards executing. This is the latent trap, not a reported bug.

#1318 hits the same shape for :services:api:integrationTest and declares the shard number as a task input:

inputs.property("shardTotal", shardTotal)
inputs.property("shardIndex", shardIndex)

Two lines, and each slice becomes its own task for hashing purposes. The same two lines belong in tests/system/build.gradle.kts.

Acceptance

• The shard number is a declared input of the system-test task.
• A run confirms each shard executes rather than resolving from cache — the Shard N/6 — x/y test classes line appears in all six.

[ExtraToast]

Part of #1321.