Regenerate .test_durations, which was blind to a whole module

[amburger66]

Regenerates .test_durations, which CI uses to balance its eight shards and which had drifted badly out of date.

Why

.github/workflows/predicators.yml:31 runs:

pytest -s tests/ --splits 8 --group ${{ matrix.group }} --splitting-algorithm least_duration

least_duration bin-packs tests into groups using the committed .test_durations. The file in master was generated on 6 August and holds 4707 entries — with zero for anything under code_sim_learning, a module that arrived with #135. pytest-split assigns unlisted tests a fallback duration, so a block of ~33 identically-estimated tests is exactly the input that makes bin-packing swing.

The visible consequence is that adding any test reshuffles which tests share a shard process, and that regrouping has been surfacing a pre-existing fragility in the NSRT/GNN learning path — dill raising TypeError: cannot pickle '_abc._abc_data' object inside nsrt_learning_approach._learn_nsrts.

Measured on a PR that adds two tests, comparing its shard 8 against master's:

• master shard 8: 910 tests across 86 file-lines
• that PR's shard 8: 913 tests across 89 file-lines
• 95 of ~175 file-lines differ in test count

So test_gnn_action_policy_approach runs in shard 8 in both, but with a substantially different set of tests preceding it in the same process. Because the split is deterministic given (test set, .test_durations), the same regrouping recurs every run — which is why that shard failed twice identically rather than flapping.

Note the file-level view is misleading here: shard 8's file lists are byte-identical between the two. pytest-split splits at test granularity, so identical file lists prove nothing. Count tests.

What this does and does not fix

Does: makes the split reflect the actual test set, so a PR adding tests no longer perturbs grouping out of proportion to what it changed.

Does not: fix the dill fragility. This re-rolls the grouping; it does not make the NSRT/GNN path robust to what precedes it in a process. That is a real bug in master and is worth its own investigation — the reproducible handle is CI's shard 8.

Caveats worth reviewing

• These durations come from a developer machine, not a CI runner. least_duration cares about relative weights and machine speed differences are broadly uniform, so the balance should transfer — but anything with a different CPU/GPU profile locally than on the runner may be mis-weighted.
• This reshuffles groups once for everyone when it lands. That is the point, but it means the first CI run after merge may surface the fragility above in a new place before settling.
• Generated from a full single-process green run at 1d809f3, so no duration here is the time a test took to fail.

Unrelated, and still unexplained

There is a separate local symptom that this does not explain and that should not be conflated with it: the full suite run in one process, at a fixed commit, with identical execution order and PYTHONHASHSEED=0 pinned, has produced 9 failures on one run and 0 on the next. Execution order, pytest-randomly, hash randomisation and git hooks are all ruled out as mechanisms. That one is open.

[yichao-liang]

ok I'll trust you on this :D