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/36380128221

• Newest run in the set: 36380128221, commit eee0974236c87a7232f9805a19b6e53e3e36da59 — 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: 1023s  |  2: 757s  |  3: 957s  |  4: 728s  |  5: 728s  |  6: 619s

Predicted bins, before and after

BEFORE  partition-test-shards: self-test OK (70 measured packages -> 71 shard items, 6 shards, max/mean 1.00x <= 1.3x, floor 404s, bins 666/666/666/667/666/666s)
AFTER   file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:967
        throw new Error(
              ^

Error: slice derivation: UNSLICED, @objectstack/cli at 1231.52s is 1391s against a 1321s mean and now fits under 1.3x on its own, so the two cases above no longer prove the slicing is what satisfies the bound. Re-derive the slice count (or retire it) instead of leaving a pin that cannot fail.
    at file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:967:15
    at check (file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:694:5)
    at selfTest (file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:965:5)
    at main (file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:1513:9)
    at file:///home/runner/work/objectstack/objectstack/scripts/partition-test-shards.mjs:1579:3
    at ModuleJob.run (node:internal/modules/esm/module_job:343:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:681:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:117:5)

Node.js v22.23.2

The partitioner's own pins RED on this refresh — read this before merging

This is the designed behaviour, not a defect in the refresh: the acceptance bound is
a ratio, and a package that has grown past what any six-way split can bin makes the
pins fail with the arithmetic in the message. The remedy the partitioner names is to
raise the file-level slice count for that package — ⛔ never to raise the bound, and
⛔ never to hand-edit this dataset. This workflow deliberately does neither: it
reports and stops, because both are decisions.

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.