TPU: XLA recompiles on the ground-truth box-count tuple, not just image shape #1433

Problem

On TPU, XLA keys its compiled graph on the per-image ground-truth box-count tuple, not only on image shape. #1058's Task 1.5 covers image-shape variance (multi_scale); this is a second axis it doesn't mention.

With image shape held constant, a repeated tuple runs in 0.18 s and a new one costs ~47 s plus 4 fresh compilations. Tested as a predictor over 30 steps:

On COCO (0–93 objects/image) that space is effectively unbounded, so a run never reaches steady state.

Impact

Padding each training image's targets to a fixed row count in collate, measured on the same 15 steps and data:

7.4× on a v5litepod-4; −55.62% median fit time on a v6e-1. The unpadded baseline also climbs to 30 GB RSS, because every new shape leaves another compiled graph cached.

It is semantically transparent, not an approximation: over 40 random batches the Hungarian assignment on real targets is identical, loss_ce is bit-identical, and box terms differ only in float32 summation order. Padded columns get a query-independent matcher cost, so they cannot displace a real target. Only the training loader would be padded — padding eval would feed filler rows to COCO matching.

Questions before implementing

1. Is a TrainConfig field (e.g. pad_targets_to) the shape you want, defaulting off?
2. How should it compose with pack_targets (perf(training): pack per-sample targets across the DataLoader boundary #1399)? Both touch the same collate seam. Pad-then-pack looks natural and should make packing more uniform, but that's a design call.
3. One global pad size, or buckets? Measured 8 → 64 costs only 16% throughput (sublinear), so bucketing looks hard to justify.

@Borda, Happy to open the PR once the approach is agreed

Refs #1058.