chore(ci): refresh the Test Core shard-timings dataset

[github-actions]

Refreshes scripts/test-shard-timings.json, the balancing input for the Test Core
shard split. Opened automatically by .github/workflows/shard-timings-refresh.yml.
Every byte came out of scripts/measure-test-shard-timings.mjs; nothing here was
hand-edited, and no bound, timeout or matrix entry was touched.

Source

Measured across 1 accumulated run(s) of the HOURLY schedule run of CI on
main — the full-battery run (#16467). A push run on main is affected-only and
is not a measurement of the workspace, so no push run feeds this file.

No single green run measures the whole workspace either — turbo's cache is namespaced
per shard and only main pushes write it, so a
package whose inputs have not changed is a HIT and the generator refuses hits rather
than recording a replay as a duration. Runs are therefore accumulated, each fenced by
its own --run group, until every package the committed dataset holds is measured
again; a package seen in several of them gets the median of those observations.

• https://github.com/objectstack-ai/objectstack/actions/runs/37262126122

• Newest run in the set: 37262126122, commit 75ddcd1b41e74823b7bb9f3fe9e159a189fa2a91 — the date this refresh carries.

• Every run above had all six Test Core (N/6) jobs conclude success with its six
  run-summary artifacts still retained; runs that were cancelled, failed or had lost
  their artifacts were rejected by name in the log before any of these were used.

All 72 package weights were measured in these runs; nothing was carried.

⚠️ This PR references #16173 and #16222 but does NOT carry a closing keyword for them,
because a weekly lane cannot know which cards a given run ought to retire. If this is
the first refresh to land, retire those two by hand as part of merging it.

Measured per-shard suite time on the newest run in the set

1: 759s  |  2: 2100s  |  3: 844s  |  4: 647s  |  5: 802s  |  6: 796s

Predicted bins, before and after

BEFORE  partition-test-shards: self-test OK (72 measured packages -> 72 shard items, 6 shards, max/mean 1.12x <= 1.3x, floor 1391s, bins 1391/1208/1206/1208/1208/1208s, file-level slices: none)
AFTER   partition-test-shards: self-test OK (72 measured packages -> 72 shard items, 6 shards, max/mean 1.04x <= 1.3x, floor 1703s, bins 1703/1615/1615/1615/1617/1616s, file-level slices: none)

No checks will start on this PR by themselves

It was opened with the Actions GITHUB_TOKEN, and GitHub's recursion guard means a
PR opened that way triggers no workflow runs. Push any commit to the branch, or close
and reopen the PR, to start CI.

Refs #16464, #16173, #16222.

[objectstack-fleet]

Stand-down note from the domain:devx seat 1 · session_01VDtqoecgES7ScQYGbFVDRv · 2026-10-06T00:54Z.

The merge queue dropped this PR (CI_FAILURE). The failure is not this PR's.

• Failing check: Lint & Type Check → job Lint & Repo Gates → step PM dispatch-gates self-test, in merge-group run 37393301718. The step reported "1 of 1976 case(s) failed".
• Why it is not this PR's:
  • The same step fails in main's own scheduled full run 37394652870, at be97cf3c93, which does not contain this PR.
  • The hourly card hourly full run: red on main (Lint & Type Check) #21924 (p1) tracks that red on main.
  • This PR changes only scripts/test-shard-timings.json. Every PR-stage check passed on head 18a0dad5bb.
• Fix: none exists yet; hourly full run: red on main (Lint & Type Check) #21924 is open. No change is ported here, because the cause is outside this diff.

This PR goes back into the queue once main's full run is green again.

---

Generated by Claude Code