Do not re-push an indivisible span while later gaps still split

subdivideToFactor splits EVERY remaining gap, so a splittable gap later in the branch grows the checkpoint list even when the current span is already one commit. The growth branch ran before classification, so that growth triggered a retry — and a one-commit gap has no midpoint to gain, so the retry re-fetched and re-pushed a byte-identical pack. Repeated once per later split, that is the same doomed upload several times in one run, and on a deadline at the announced ceiling each repeat is multi-GiB.

Subdividing is now attempted only when the current span can actually shrink. When it cannot, there is nothing to retry for: fall through and classify, which either returns the target's size verdict or a retryable error whose redelivery re-plans from the temp ref.

Pinned by a 5-commit chain planned into 4 batches, which yields gaps of 1,1,1,2 — the first checkpoint indivisible while the last gap can still split — failing on a deadline so the old code took the growth path. Two pushes of the identical pack before, one after.