Tarball space preflight under-asks when a cached download is being replaced

The SDK tarball preflight asks for archive + margin before downloading. It does not account for a copy of the archive that is already in the cache.

install_tarball_runtime has no cache-hit check, so a re-run always re-downloads, and write_file_atomically writes a sibling temp file and then renames. During that window both the existing cached copy and the new one are on disk, so the true peak is archive + existing cached copy + margin while the preflight asks for only one of them.

This under-asks, so the consequence is a late failure rather than a false refusal — strictly the safer direction, and the out-of-space message is now mapped either way. It is still a real gap in the estimate.

Two ways forward, probably both: check for a usable cached artifact and skip the download entirely (engines/lemonade/src/lib.rs already implements that pattern), and include the size of any existing destination file in the requirement.

Split out of the review of #171 to keep that change to one concern.

Start at install_tarball_runtime and write_file_atomically, then compare the cache-hit behavior in engines/lemonade/src/lib.rs. Confirm that a usable cached artifact skips the download and that preflight includes any existing destination file alongside the archive and margin. Done means the peak temporary disk usage is accurately estimated and reruns avoid unnecessary replacement downloads.