Use projected pack size for factor & objectsSent for calibration

Two refinements that fall out of having the streaming pack observer feeding live counters during the upload.

1. observedSubdivisionFactor was being called with sentBytes, which after a self-imposed early abort is just the abort-point floor (~minBytesBeforeAbort = 8 MiB) — far below the actual pack size. The factor came out as 2 every round, so the loop doubled the pack count one step at a time (1→2→4→…) instead of making informed jumps. When abortedEarly, project from observed bytes/object to the full pack size (sentBytes × totalObjects ÷ objectsSent) and feed that to the factor calculation. For a blob-front-loaded repo the first round now jumps 1→8 instead of 1→2.

2. calibrateBytesPerObject was dividing sentBytes by the full pack header object count, which understates the per-object byte size when the upload only covered the front of the pack. Use objectsSent (the count actually observed by the streaming parser) instead — sentBytes/objectsSent is the accurate per-object average for the portion we saw, and that's the pessimistic upper bound the pre-flight wants. For the user's scenario this jumped the calibrated estimate from "no update" (8M÷65k = 256 < default 750) to 29 KiB/object, which is what actually catches subsequent oversized sub-packs in the pre-flight check on the next attempt.