feat(devx): red the Test Core shard when its predicted time stops matching the measured one

scripts/test-shard-timings.json is generated and nothing re-measured it, so it
rots in one direction only: suites get slower, the file stays put, and the shard
that drifted heavy reads as perfectly balanced right up until the 30-minute wall
kills it. Measured on run 34009395649: @objectstack/cli predicted 458.15s, ran
1231.52s (2.69x) while the split's own banner read max/mean 1.00x.

partition-test-shards.mjs gains --check-drift, and every Test Core shard now runs
it over the summary --summarize has just written. It reuses the generator's
samplesFromSummary so a cache replay cannot be read as a fast suite, compares
only the intersection of measured-and-predicted packages, and reports NOT
MEASURED as its own verdict rather than as a pass.

The bound is 1.5x, where the populations separate on green merge_group build
34013842594: five healthy shards at 0.69-1.18x, the drifted one at 1.74x.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vbw3RPgdtqesx4azk9SbW8

Author: claude

scripts/partition-test-shards.mjs

@@ -143,14 +143,32 @@ export const MAX_SHARD_OVER_MEAN = 1.3;
 // balanced. Nothing in this repo compared a prediction to an outcome, so the
 // only instrument that ever noticed was a killed job.
 //
-// 1.5 is the smallest round factor satisfying both ends:
+// 1.5 is where the two populations actually separate, measured rather than
+// picked. On run 34013842594 -- a GREEN merge_group build, so the full package
+// list rather than a pull_request's --affected subset -- the six shards ran
+// their `Run this shard's tests` step against the same 672s prediction:
+//
+//   shard 3  462s  0.69x     shard 6  776s  1.15x
+//   shard 5  630s  0.94x     shard 4  793s  1.18x
+//   shard 2  714s  1.06x     shard 1 1168s  1.74x   <- the one carrying the CLI
+//
+// Five healthy shards top out at 1.18x and the drifted one sits at 1.74x, on
+// the same build, so the gap is not runner noise and one factor separates them
+// cleanly. (Those step times include turbo scheduling and any uncached build
+// tasks; this gate compares test-task windows only, which is the tighter and
+// fairer reading of the same shards.)
+//
+// 1.5 also satisfies the two ends the bound is answerable to:
 //
 //   - it must fire well below the 2.69x measured above, or the gate would have
 //     been green straight through the incident it exists to catch;
 //   - it must sit ABOVE MAX_SHARD_OVER_MEAN, because a dataset accurate to
 //     within the balance bound cannot be the thing that breaks balance. Gating
 //     tighter than the split's own tolerance reds on drift the partitioner is
 //     built to absorb, and a gate that reds on healthy input gets muted.
+//
+// ⛔ Raising this to absorb a red is the one move that cannot be right: the
+// number it would be raised past is a measurement of the dataset being wrong.
 export const MAX_MEASURED_OVER_PREDICTED = 1.5;
 
 // Where a `packages.items[].path` actually points.