fix(ci): break shard ties on bucket count so a thin durations file cannot collapse (#14802)

[mrveiss]

Closes #14802. Blocks-fix for #14648.

Thinking Path

build_bucket_table assigns buckets to shards by greedy longest-processing-time:

target = min(range(splits), key=lambda s: (shard_load[s], s))
table[bucket] = target
shard_load[target] += bucket_weight[bucket]

A zero-weight bucket adds nothing to shard_load. So once a shard holds the
minimum load it keeps winning the tie, and every weightless bucket after it lands on
that same shard. The shards past it receive nothing.

Reproduced against a standalone reimplementation of the published algorithm, not by
running repo code:

durations input	shards used, before	after
empty / missing	1 of 12	12 of 12
one module	2 of 12	12 of 12
five modules	6 of 12	12 of 12
realistic, ~1282 modules	12 of 12	12 of 12

The important part is that it is structural, not transient. Assignment is by
hash, so a shard that receives no bucket cannot be reached by any file added later
either. Under the one-module case, 5000 hypothetical new modules hashed into shards
[0, 1] only.

Why it was invisible

The committed .test_durations describes ~1282 modules, so all twelve shards are
used and the spread is fine. The collapse needs a missing, empty, truncated or very
thin durations file — and those are committed by hand from a workflow artifact, with
no non-degeneracy check before commit.

The existing test looked like it covered this:

assert set(table) <= set(range(SPLITS))

<= is satisfied when one shard of twelve is used. The degenerate case read as
covered while being untested.

Why it matters now

#14648 is what activates this algorithm in CI. Its SLM step tolerates pytest's
exit 5 (no tests collected) and returns 0 — written for the legitimate "fewer
modules than shards" case. Combined with a collapse, eleven of twelve SLM shards
would each exit 0 with a ::notice::, one shard would silently run the whole suite,
and the aggregator would report that every shard passed.

That is worse than the exit-5 redness this repo has already been bitten by: it turns
the failure green instead of red.

It is also a regression against the old behaviour — pytest-split degrades to
equal-count contiguous chunks across all groups when durations are missing.

What Changed

Tie-break on a per-shard bucket count as well as load, incremented unconditionally,
so weightless buckets round-robin instead of piling up.

Verification

Each new test run against both algorithms:

no-durations   OLD: FAIL (1/12)    NEW: PASS (12/12)
one-module     OLD: FAIL (2/12)    NEW: PASS (12/12)
five-modules   OLD: FAIL (6/12)    NEW: PASS (12/12)
future modules OLD: FAIL (reached [0, 1])   NEW: PASS (reached all 12)
realistic      OLD: spread 1.001x  NEW: spread 1.001x   (unchanged)

Every one fails against the old tie-break, so none of them is decorative, and the
realistic distribution is untouched — this fixes the degenerate case without
perturbing the balanced one.

Model Used

Claude Opus 5

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No hardcoded values detected that have SSOT config equivalents!