Let the target decide when a bootstrap checkpoint cannot be split further

A batched bootstrap that reached a single indivisible commit failed outright, even though the failure was our own doing: TargetMaxPack is deliberately well under what the server accepts, the observer aborts at 95% of it, and nothing ever asked the target whether it would take the pack. gh/nicschick/vc3r dies exactly here — subdivision bottoms out at one commit, our 512 MiB budget aborts the upload, and the run fails against a target that announced it accepts 10 GiB.

The batching budget stays small on purpose (a doomed or interrupted push wastes less, and the temp ref advances more often), so rather than raise it this records what the target actually announced and uses it only at the point where subdivision has run out: the checkpoint is retried once with the ceiling raised to the target's own limit, and the target returns the verdict.

That verdict is what makes the failure classifiable. A self-imposed abort stays retryable — a larger budget or a config change could still mirror the repo — while a checkpoint that is indivisible AND over the target's own limit now returns ErrCheckpointExceedsTargetLimit, which callers can treat as permanent instead of redelivering an identical pack ten times. Only object-level splitting or a larger server limit can fix that case, and this is what proves the repo is in it.

Also stops discarding the bootstrap Result when Execute fails: the strategy facts (RelayMode, RelayReason, batch counts, temp refs) are populated before anything can go wrong and describe the route taken, not the outcome. Zeroing them is why a failed sync could report which strategy ran only when it succeeded — the same blind spot that made ENT-2054 a source read rather than a log query.