Support retry and resume for direct IPSW downloads in `tart create --from-ipsw`

[TyceHerrman]

Problem

tart create --from-ipsw <remote-url> currently downloads the complete IPSW through one URLSession request. If that request fails after transferring several gigabytes, Tart exits and leaves a partial file under $TART_HOME/tmp, but a subsequent invocation cannot retry or resume that download.

This is especially costly for current macOS IPSWs, which can exceed 20 GiB.

Reproduction

• Tart: 2.34.0
• Host: macOS 27.0 (26A5388g)
• Invocation: native interactive Terminal
• Source: Apple CDN

tart create test-vm \
  --from-ipsw 'https://updates.cdn-apple.com/2026SummerSeed/fullrestores/140-55718/5809AFC6-1923-4590-AAFC-904A0283E659/UniversalMac_27.0_26A5388g_Restore.ipsw' \
  --disk-size 50 \
  --disk-format asif

The download reached 20% and then failed:

Fetching UniversalMac_27.0_26A5388g_Restore.ipsw...
20%
Error: A TLS error caused the secure connection to fail.

Afterward:

• $TART_HOME/tmp/<UUID>.ipsw contained 4,658,109,431 bytes.
• No completed IPSW cache entry existed.
• No VM had been created.
• Rerunning could not reuse the partial file.

The initial TLS connection had transferred several gigabytes, so this was not an immediate URL or certificate rejection. Regardless of the underlying transient network failure, losing all progress makes direct IPSW creation fragile.

Requested behavior

Please consider adding bounded retry and resumable downloads for remote IPSWs:

1. Retry transient URL-loading and network errors with bounded exponential backoff.
2. Preserve partial IPSWs across retries and process restarts.
3. Resume with HTTP Range plus a stable validator such as ETag or Last-Modified/If-Range.
4. Require and validate a correct 206 Partial Content response and Content-Range offset.
5. Restart safely from byte zero if the source changed or the server does not support ranges.
6. Verify the complete file digest before promoting it into the IPSW cache.
7. Garbage-collect stale partial files using an explicit age or size policy.

Related work

Existing resume and retry work appears to cover OCI registry image pulls, not direct IPSW URLs:

• #444 — macOS image downloading resume
• #561 — resuming of downloads, closed unmerged
• #589 — OCI resumable pulls, merged
• #788 — retry VM pull with exponential backoff, merged
• #947 — retry URLError during VM pulls, merged

Current Fetcher.swift still streams a single URLSessionDataTask and forwards completion errors without retry, range handling, or partial-file reuse. Direct IPSW support would complement the reliability already implemented for tart pull.