Replace probe-based bootstrap checkpoint planning with estimate

The previous checkpoint planner did full FetchPack round-trips per probe candidate to measure actual pack sizes, then binary-searched for the boundary that fit under --batch-max-pack-bytes. For linux/master (75k commits) this took 13+ fetch-and-discard cycles — downloading gigabytes of throwaway data and burning minutes — before any real push started. The precision was rarely needed: the adaptive retry and resume mechanisms already handle batches that turn out too large.

Replace with estimate-based planning:

1. Fetch the commit graph (tree:0 filter, one round-trip — unchanged).
2. Walk the first-parent chain to get commit count (unchanged).
3. Estimate total pack size as chainLen × 8 KiB/commit.
4. Divide into ceil(estimated / batchMaxPack) evenly-spaced checkpoints.
5. Done. No probe fetches.

For linux at 1 GiB batch limit: planning goes from ~4 minutes / 13 fetches to ~20 seconds / 1 fetch (just the commit graph). The estimate is intentionally conservative (8 KiB vs the old 4 KiB) so it errs toward more batches rather than fewer. If a batch still exceeds the target's limit, the push fails for that batch and bootstrap resume (via temp refs) ensures already-pushed batches aren't re-sent on the next run.

Deleted ~535 lines of probe infrastructure:

• checkpointPlanner struct and all methods
• fetchPackForProbe, probeKey, probeResult, probeBounds
• initialCheckpointSpan, adaptiveNextProbeSpan
• shouldProbeTipFirst, shouldSelectTipWithoutProbe
• nextCheckpointProbeCandidate, searchCheckpointUnderLimit
• prefetchedPacks field on plannedBatch and its lookup in packReaderForCheckpoint

Added:

• estimateBatchCount (ceil division with 8 KiB heuristic)
• evenCheckpoints (evenly-spaced placement along the chain)
• TestEstimateBatchCount and TestEvenCheckpoints